| Age | Commit message (Collapse) | Author |
|
switching between (sub)grids (fixes #1663)
Given in.txt with
53.999759140 5.144478208 252.6995
Before the fix,
cct -t 0 -d 4 +proj=pipeline +step +proj=axisswap +order=2,1,3,4 +step +proj=hgridshift +inv +grids=rdtrans2018.gsb +step +proj=vgridshift +grids=naptrans2018.gtx +step +proj=sterea +lat_0=52.156160556 +lon_0=5.387638889 +k=0.9999079 +x_0=155000 +y_0=463000 +ellps=bessel in.txt
returned:
139079.8814 668306.0302 212.1724 0.0000
It now returns:
139079.8850 668306.0458 212.1724 0.0000
which meets with the 1mm accuracy the expected result of test point
```
30010049 53.999759140 5.144478208 252.6995 139079.8850 668306.0460 212.1723
```
|
|
|
|
Related to https://github.com/OSGeo/proj-datumgrid/pull/66
Tune operation search so that it can work with Geog2D <--> VertCS for commandline
niceness
|
|
Relates to https://github.com/OSGeo/proj-datumgrid/pull/65 ,
https://github.com/OSGeo/proj-datumgrid/issues/22
As EPSG has no entry for it, we create a grid_transformation, as well as a
dedicated area of use based on the extent of the grid, under the PROJ authority.
With the hope to be able to remove it once EPSG has an entry...
|
|
intermediates B and C, such there's a A->B operation and C->D operation, and A and C are not exactly the same CRS but use the same geodetic datum
|
|
result through ITRF2008. Was broken in master by the addition of the 'WGS84 -> WGS 84 (Gxxx)' null operations in the PROJ authority
|
|
alternatives, to select the operation with best accuracy
|
|
03, 06, 09 and 18. Related to https://github.com/OSGeo/proj-datumgrid/pull/60 that add those grids in proj-datumgrid-north-america
|
|
|
|
arbitrary number of steps (fixes #1632)
EPSG:9103 (NAD27 to ITRF2014 (1)) is now handled.
Note:EPSG:9104 (NAD27 to ITRF2014 (2)) is not currently, since it uses
for step EPSG:8861 (NAD83(HARN) to NAD83(FBN) (1))
an unsupported transformation method (NADCON5 (3D), EPSG:1075).
|
|
Note: a hack has been added into customizations.sql to cancel deprecatation
of USA geoid2012 grids by geoid2018 grids, as the later are not yet available
in proj-datumgrid-northamerica (https://github.com/OSGeo/proj-datumgrid/issues/55)
|
|
verticalCRS to a 2D CRS
|
|
pipelines at end
|
|
With limitation of https://github.com/OSGeo/PROJ/issues/1632 regarding
concatenated operations with more than 3 steps.
|
|
createOperations(), and test it (fixes #1623)
|
|
|
|
|
|
proj_crs_create_projected_3D_crs_from_2D() (fixes #1587)
Also add a --3d switch to projinfo
|
|
- C API: PJ_GUESSED_WKT2_2019 is added, PJ_GUESSED_WKT2_2018 aliased to it
- C API: PJ_WKT2_2019[_SIMPLIFIED] is added, PJ_WKT2_2018[_SIMPLIFIED] alias to it
- C++ API: similarly for WKTFormatter::Convention::WKT2_2019[_SIMPLIFIED]
Those above changes should be fully backward API and ABI compatible.
projinfo changes:
- accept WKT2_2019 as value for -o switch. WKT2_2018 is still accepted (undocumented)
- output now uses 'WKT2_2019 string:', so might break scripts that would rely on that.
Other internal code references to WKT2_2018 changes to WKT2_2019, included
in tests.
|
|
with longitudes outside of [-180,180]
|
|
to exported PROJJSON strings
|
|
|
|
|
|
|
|
- Import scope and remarks for coordinate operations of the EPSG dataset.
Database size goes from 5.2 MB to 5.55 MB
- Add proj_get_scope() and proj_get_remarks()
|
|
to be able to chain with unitconvert (fixes #1525)
|
|
RAF18
|
|
|
|
SWEREF99' transformation
|
|
- Tests should use unified diff with expected results
- Show CMake build compile commands (VERBOSE=1)
- Travis CI only has two cores, so "-j2" is sufficent
|
|
|
|
|
|
|
|
even if there is one on upper node
This is a particular logic allowed by paragraph 7.3.3 Identifier
of OGC 18-010r6
|
|
This is a particular logic allowed by paragraph 7.3.3 Identifier
of OGC 18-010r6
|
|
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
|
|
|
|
All other tests use PROJ_LIB, and allow it to be overridden from the
command-line, so do the same here.
|
|
|
|
horizontal transformation
|
|
|
|
|
|
used to know if it includes a very approximative transformation term
|
|
more results
|
|
transformation when needed, and also sort Null geographic offset transformation in last
|
|
the push/pop v_3 operator to preserve the Z component
|
|
|
|
|
|
|
|
* 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>
|