aboutsummaryrefslogtreecommitdiff
path: root/test/cli
AgeCommit message (Collapse)Author
2021-07-20Merge pull request #2782 from rouault/fix_crs_extent_use_noneEven Rouault
createOperations(): fix SourceTargetCRSExtentUse::NONE mode
2021-06-17proj_trans/cs2cs: If two operations have the same accuracy, use the one that ↵Even Rouault
is contained within a larger one Relates to https://github.com/OSGeo/gdal/issues/3998 Before that change, cs2cs on a NAD83(HARN) to WGS84 transformation would use the "NAD83(HARN) to WGS 84 (1)" transformation (a null Helmert shift) that is valid for whole US, including non-CONUS areas, even when used on points located on CONUS that has a "NAD83(HARN) to WGS 84 (3)" transformation (non-null Helmert shift) with same accuracy (1m). But if doing EPSG:2874 "NAD83(HARN) / California zone 5 (ftUS)" to WGS84, we would use this later "NAD83(HARN) to WGS 84 (3)" transformation because the area of use of EPSG:2874 restricts to CONUS. This isn't consistant. With that change, we now have more consistent behavior, even if it can be argued which of the 2 transformations is the best... $ echo 34 -120 | src/cs2cs -d 8 EPSG:4326 "NAD83(HARN)" | src/cs2cs "NAD83(HARN)" EPSG:2874 5955507.74 1828410.98 0.00 $ echo 34 -120 | src/cs2cs EPSG:4326 EPSG:2874 5955507.74 1828410.98 0.00
2021-05-24Database: decrease DB size by using WITHOUT ROWID tablesEven Rouault
None of our tables are indexed by a INTEGER PRIMARY KEY, but most of them are by a (auth_name, code) primary key. Consequently they can benefit from being created as WITHOUT ROWID tables (https://sqlite.org/withoutrowid.html), which avoids an index to be created on the rowid we don't use. WITHOUT ROWID is a feature added in SQLite 3.8.2, so as our baseline is 3.11, we can use it. This decreases the DB size from 7,749,632 to 7,229,440 bytes, without any measurable consequence on performance.
2021-05-17projsync: make it filter out files not intended for the current versionEven Rouault
* Add a PROJ_DATA.VERSION in proj.db to indicate the target PROJ-data package version * Make projsync use that information and the version_added and version_removed properties added in https://github.com/OSGeo/PROJ-data/pull/67 to filter out files that are not relevant * Add --no-version-filtering and --verbose switches
2021-05-16Database: update to EPSG v10.022Even Rouault
2021-04-23Move data/proj_outIGNF.dist-real to test/cliEven Rouault
2021-04-23Database: update to EPSG v10.019Even Rouault
Non-trivial updates: - some vertical CRS are now encoded as DerivedVerticalCRS. e.g EPSG:8228 "NAVD88 height (ft)", with base EPSG:5703 "NAVD88 height". As we don't have support in our PROJ db model for DerivedVerticalCRS, modify the import script to 'resolve' the derivation up to the original datum. - Method EPSG:1069 'Change of Vertical Unit' is no longer used. It is replaced by a generic-purpose EPSG:1104 method that doesn't take any conversion factor. And generic conversions EPSG:7812 and EPSG:7813 are now used in concatenated operations, which require code changes as well.
2021-04-12Merge pull request #2659 from rouault/fix_2603Even Rouault
CRS::normalizeForVisualization(): propagate domains/extent of original CRS (fixes #2603)
2021-04-11projinfo --list-crs --area: make it work when multiple areas matches the ↵Even Rouault
specified name
2021-04-11projinfo: add option --list-crs (#2663)Javier Jimenez Shaw
2021-04-11projinfo: add a --normalize-axis-order undocument switchEven Rouault
2021-04-08Merge pull request #2647 from rouault/integer_or_textEven Rouault
Database: decrease db size
2021-04-07test: add datum shift related tests for transformations crossing antimeridianEven Rouault
If using the proposed patch in PR #2616 refreshed as, ``` diff --git a/src/4D_api.cpp b/src/4D_api.cpp index c7725d3a..3bd58a97 100644 --- a/src/4D_api.cpp +++ b/src/4D_api.cpp @@ -998,7 +998,7 @@ static void reproject_bbox(PJ* pjGeogToCrs, constexpr int XY_SIZE = N_STEPS_P1 * 4; std::vector<double> x(XY_SIZE); std::vector<double> y(XY_SIZE); - const double step_lon = (east_lon - west_lon) / N_STEPS; + const double step_lon = (((east_lon >= west_lon) ? east_lon : east_lon + 360) - west_lon) / N_STEPS; const double step_lat = (north_lat - south_lat) / N_STEPS; for( int j = 0; j <= N_STEPS; j++ ) { @@ -1244,7 +1244,7 @@ std::vector<PJCoordOperation> pj_create_prepared_operations(PJ_CONTEXT *ctx, { const bool isOffshore = areaName && strstr(areaName, "- offshore"); - if( west_lon <= east_lon ) + if( true || west_lon <= east_lon ) { op = add_coord_op_to_list(i, op, west_lon, south_lat, east_lon, north_lat, ``` we'd get an incorrect result on one point, using the 'Pulkovo 1942 to WGS 84 (16)' less accurate transformation due to mis-computation of bounding boxes. ``` --- ../test/cli/tv_out.dist 2021-04-07 22:29:02.706095239 +0200 +++ test/cli/tv_out 2021-04-07 22:29:35.809579495 +0200 @@ -499,7 +499,7 @@ ############################################################## Check that we can use a transformation spanning the antimeridian (should use Pulkovo 1942 to WGS 84 (20)) 50 179.999999999 49d59'59.36"N 179d59'52.133"W 0.000 -50 -179.999999999 49d59'59.36"N 179d59'52.133"W 0.000 +50 -179.999999999 49d59'59.422"N 179d59'52.184"W 0.000 ############################################################## Check that we can use a transformation spanning the antimeridian (should use Pulkovo 1942 to WGS 84 (20)) 5540944.47 499999.999 49d59'59.36"N 179d59'52.133"W 0.000 ```
2021-04-06Database: nullify auth_name, code of usage tableEven Rouault
We never select by those columns, so don't set them. Reduce from 8.4 to 7.9 MB. Upgrade the minor version of the database layout. (that database can still be read by PROJ 8.0)
2021-03-28createOperation(): make sure no to discard deprecated operations...Even Rouault
if the replacement uses a grid unknown to us. Fixes issue reported at https://lists.osgeo.org/pipermail/gdal-dev/2021-March/053771.html The issue comes from the fact that EPSG has created 2 transformations using grids BALR2009.gsb ad PENR2009.gsb that supersede the one which uses the single grid SPED2ETV2 we have in PROJ-data.
2021-03-19CRS::promoteTo3D(): propagate the extent from the 2D CRS (fixes #2587)Even Rouault
This will help getting more consistent results between the 2D and 3D cases, as identified in https://github.com/OSGeo/PROJ/issues/2587#issue-836061171
2021-03-15Add support for PROJ_AUX_DB environment variable to set the path to one or ↵Even Rouault
several auxiliary DBs
2021-03-15projinfo: add a --dump-db-structure switchEven Rouault
2021-03-15SQL output: add capability to restrict the authorities into which to look ↵Even Rouault
for intermediate objects
2021-03-15projinfo: add a '-o SQL --output-id AUTH:CODE' SQL outputEven Rouault
2021-03-11Database: fix NKG transformationsEven Rouault
2021-03-07typo fixesEven Rouault
2021-02-09Database: update to EPSG v10.012Nyall Dawson
2021-01-15Database: update to EPSG v10.011Modern Slave
2020-12-16cs2cs: add --no-ballpark and --accuracy optionsEven Rouault
2020-12-15projinfo: add a --accuracy option to define the minimum accuracyEven Rouault
2020-12-02cs2cs / proj_create_crs_to_crs_from_pj(): add a --authority switch to ↵Even Rouault
control where coordinate operations are looked for (fixes #2442)
2020-11-30Merge pull request #2466 from rouault/fix_2423Even Rouault
cs2cs: add --area and --bbox options to restrict candidate coordinate operations (fixes #2423)
2020-11-30API cleanup: unexport number of internal symbols, and remove/replace a few ↵Even Rouault
unused ones
2020-11-28cs2cs: add --area and --bbox options to restrict candidate coordinate ↵Even Rouault
operations (fixes #2423)
2020-11-28Use same arguments to printf format string for both radians and degrees in ↵Houder
output by cct (#2453) Currently the output of the cct utility is different between radians and degrees (as expected by cct), because of a bug in cct: $ printf "1 2\n" | cct -z 0 -t 0 +proj=pipeline +step +proj=unitconvert +xy_in=deg +xy_out=rad 1.0000000000 2.0000000000 0.0000 0.0000 $ printf "1 2\n" | cct -z 0 -t 0 +proj=pipeline +step +proj=unitconvert +xy_in=deg +xy_out=deg 1.0000 2.0000 0.0000 0.0000 The arguments to the printf format string are as follows: * radians: width 14, precision 10 * degrees: width 13, precision 4 (this is by mistake. bug!) After the suggested fix has been applied, output will be the same for both radians and degrees: $ printf "1 2\n" | cct -z 0 -t 0 +proj=pipeline +step +proj=unitconvert +xy_in=deg +xy_out=rad 1.0000000000 2.0000000000 0.0000 0.0000 $ printf "1 2\n" | cct -z 0 -t 0 +proj=pipeline +step +proj=unitconvert +xy_in=deg +xy_out=deg 1.0000000000 2.0000000000 0.0000 0.0000 The cause of the bug is that cct does test if it "has radians to output", but "neglects" to test if it "has degrees to output", resulting in using different arguments to the printf format string in the latter case. The fix makes cct test if it "has either radians or degrees to output".
2020-11-27testcct: create 'a' and 'b' from scratchEven Rouault
2020-11-24createOperation(): add a ballpark vertical transformation when dealing with ↵Even Rouault
GEOIDMODEL[]
2020-11-10cct: allow @filename syntaxEven Rouault
Similarly as for projinfo, allow "cct @filename" to mean read filename and use its content as if it was provided inline. Useful for WKT or PROJJSON And a tiny improvements, when the object definition contains ':', only try proj_create_from_database() if the left part (authority name) matches a known authority, to avoid a warning.
2020-11-10Allow cct to instantiate operations via object codes or names (#2419)Kristian Evers
Running cct like cct EPSG:8366 or cct "ITRF2014 to ETRF2014 (1)" is now possible.
2020-11-01projinfo / createObjectsFromName(): support returning a datum ensembleEven Rouault
2020-11-01When reading from database, possibly return Geographic/GeodeticCRS with a ↵Even Rouault
DatumEnsemble, typically for WGS 84 and ETRS89 ('breaking change')
2020-10-31Make sure that remarks is preserved when substituting (EPSG) grid name by ↵Even Rouault
PROJ one
2020-10-25Add +proj=col_urban projection, implementing a EPSG projection method used ↵Even Rouault
by a number of projected CRS in Colombia (fixes #589)
2020-10-23Database: add Finland tinshift operationsEven Rouault
2020-10-23Database: import ESRI VERTCS that uses a (geodetic) datum to express ↵Even Rouault
ellipsoidal height
2020-10-16projinfo: restrict PROJ multiline output to coordinate operations onlyEven Rouault
2020-10-16Add multi-line PROJ string export capability, and use it by default in ↵Even Rouault
projinfo (unless --single-line is specified) (fixes #1543)
2020-10-16Merge pull request #2370 from rouault/epsg10Even Rouault
Update to EPSG 10.003 and make code base robust to dealing with WKT CRS with DatumEnsemble
2020-10-11Database: add a frame_reference_epoch column in vertical_datum to be able to ↵Even Rouault
handle dynamic vertical datums, and instanciate them properly from database
2020-10-08promoteTo3D(): add a remark with the original CRS identifier (fixes #2368)Even Rouault
``` $ projinfo EPSG:32631 --3d WKT2:2019 string: PROJCRS["WGS 84 / UTM zone 31N", [ ...snip ] REMARK["Promoted to 3D from EPSG:32631"]] ```
2020-10-08Database: use extended description for extent/area of use, as done by ↵Even Rouault
epsg.org WKT export
2020-10-06Database: "minimal" update to EPSG v10.003Even Rouault
Content mostly unchanged since v9.9 This update is "minimal" in that it mostly reflects the removal of the 'area' table, replaced now by 'extent', 'scope' and 'usage' Other new aspects of EPSG v10 are left aside.
2020-09-17createOperations(): tune sorting of transformations so that the ones with ↵Even Rouault
greater 'version numbers' are prefered over other ones, when all other comparison criteria are equal. Helps with Amersfoort RD New to EPSG:4326
2020-09-17Adjust createBoundCRSToWGS84IfPossible() and operation filtering (for POSGAR ↵Even Rouault
2007 to WGS84 issues) (fixes #2356) - We make createBoundCRSToWGS84IfPossible() more restrictive. If there are more than one Helmert transformation from the CRS to WGS 84 covering the area of use of the CRS, we do not create a BoundCRS / +towgs84 - In createOperations() filtering, we are less aggressive in discarding operations that have the same area of use but worse accuracy. We do it only if they involve more transformation steps. We now get: ``` $ projinfo EPSG:5340 -o PROJ PROJ.4 string: +proj=longlat +ellps=GRS80 +no_defs +type=crs $ projinfo -s EPSG:5340 -t EPSG:4326 --spatial-test intersects --summary Candidate operations found: 2 EPSG:9264, POSGAR 2007 to WGS 84 (2), 0.5 m, Argentina EPSG:5351, POSGAR 2007 to WGS 84 (1), 1.0 m, Argentina ```
generated by cgit v1.2.3 (git 2.25.1) at 2025-12-15 19:44:22 +0000