aboutsummaryrefslogtreecommitdiff
path: root/test/cli/tv_out.dist
AgeCommit message (Collapse)Author
2021-09-15test/cli/testvarious: make one test more robust regarding EPSG updatesEven Rouault
2021-09-08createOperations(): deal with spherical planetocentric geodetic CRSEven Rouault
This also fixes conversion between geocentric latlong and geodetic latlong with cs2cs. This was dealt with in PR 1093, but in the wrong direction (the geocentric latitude must be <= in absolute value to the geodetic one) The issue here was linked to the semantics of the +geoc specifier, which affects the semantics of the input coordinates in the forward direction (+geoc means that the input coordinate is is a geocentric latitude), which defeats the logic of doing A to B by using the inverse path of A and the forward path of B.
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-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 ```
2020-12-16cs2cs: add --no-ballpark and --accuracy optionsEven 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-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-03-18cs2cs: don't require +to for '{source_crs} {target_crs} filename...' syntax ↵Even Rouault
(fixes #2012)
2019-08-26Fix 6.0 regression regarding +init=epsg:4326 +over +to +init=epsg:3857 +over ↵Even Rouault
with longitudes outside of [-180,180]
2019-06-22+proj=ob_tran +o_proj=longlat: set right unit to PJ_IO_UNITS_WHATEVER so as ↵Even Rouault
to be able to chain with unitconvert (fixes #1525)
2019-05-03cs2cs: set time value to HUGE_VAL if not explicitly specifiedEven Rouault
2019-03-24Make cs2cs support 4D coordinates.Kristian Evers
This is a bit of a hack, 4D coordinates *will* be written to STDOUT but the output format speficied with -f is not respected for the t component, rather it is forward verbatim from the input. Fixes #1354
2019-02-13EPSG Helmert and Molodensky-Badekas methods in the Geographic 2D domain: use ↵Even Rouault
the push/pop v_3 operator to preserve the Z component
2019-02-11Make tmerc an alias for etmerc. (#1234)Kristian Evers
* Make tmerc an alias for etmerc This switches the algorithm used in tmerc to the Poder/Engsager tmerc algorithm. The original tmerc algorithm of Evenden/Snyder origin can still be accessed by adding the +approx flag when initializing a tmerc projection. The +approx flag can also be used when initializing UTM projections, in which case the Evenden/Snyder algorithm is used as well. If a tmerc projection is instantiated on a spherical earth the Evenden/Snyder algorithm is used as well since the Poder/Engsager algorithm is only defined on the ellipsoid. +proj=etmerc can still be instantiated for backwards compatibility reasons. Co-authored-by: Kristian Evers <kristianevers@gmail.com> Co-authored-by: Even Rouault <even.rouault@spatialys.com>
2018-12-01Rename test/old/ to test/cli/ to better reflect their natureEven Rouault
generated by cgit v1.2.3 (git 2.25.1) at 2025-12-15 20:54:10 +0000