| Age | Commit message (Collapse) | Author |
|
|
|
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>
|
|
|
|
until proj_trans() is called (fixes #1229)
|
|
|
|
|
|
CRS objects (refs #1214)
|
|
|
|
CRS with towgs84 keyword
|
|
As discussed in https://github.com/OSGeo/proj.4/issues/1214#issuecomment-452084720,
the introduction of a new PROJ.5 format to export CRS using pipeline/unitconvert/axisswap
as an attempt of improving the PROJ.4 format used by GDAL and other products is
likely a dead-end since it is still lossy in many aspects and can cause confusion
with coodinate operations.
Consequently the PROJ_5 convention will be identical to PROJ_4 for CRS export.
Note: on the import side, I've kept the code that could parse unitconvert and
axisswap when building a CRS definition from a pipeline. It is there as a hidden
feature as it was kind of a tear to remove that code in case it might still be
useful...
|