| Age | Commit message (Collapse) | Author |
|
#1823)
|
|
Make EPSG:102100 resolve to ESRI:102100 (fixes #1730)
|
|
omit_fwd/omit_inv
|
|
https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=19367
|
|
|
|
(fixes #1779)
|
|
Mercator projection, but with subtlely different parameters (fixes https://github.com/OSGeo/gdal/issues/2087)
|
|
inv constructs
Given an initial pipeline with
+step +proj=hgridshift +grids=foo
+step +proj=vgridshift +grids=bar
+step +inv +proj=hgridshift +grids=foo
Transform it as
+step +proj=push +v_1 +v_2
+step +proj=hgridshift +grids=foo +omit_inv
+step +proj=vgridshift +grids=bar
+step +inv +proj=hgridshift +grids=foo +omit_fwd
+step +proj=pop +v_1 +v_2
So as to avoid doing a double application of the hgridshift.
|
|
Inspired from syntax of https://github.com/OSGeo/PROJ/pull/453/files
but 'rebased' on top of previous commit that cleans up the pipeline implementation
Different situations:
- +omit_fwd:
the step when followed in the forward path will be omitted
the step when followed in the reverse path will be executed
- +omit_fwd +inv:
the step when followed in the forward path will be omitted
the step when followed in the reverse path will be executed (with the inv method)
- +omit_inv:
the step when followed in the forward path will be executed
the step when followed in the reverse path will be omitted
- +omit_inv +inv:
the step when followed in the forward path will be executed (with the inv method)
the step when followed in the reverse path will be omitted
This will be used in the next commit to optimize constructs like
+step +proj=hgridshift +grids=foo
+step +proj=vgridshift +grids=bar
+step +inv +proj=hgridshift +grids=foo
Such steps are used for CRS to CRS transformations where applying the vertical grid
requires to do a transformation to an interpolating CRS. One can notice that
in the last step will just restore the horizontal coordinates before the first step, so
doing an inverse hgridshift is overkill.
So that could be optimized as:
+step +proj=push +v_1 +v_2
+step +proj=hgridshift +grids=foo +omit_inv
+step +proj=vgridshift +grids=bar
+step +inv +proj=hgridshift +grids=foo +omit_fwd
+step +proj=pop +v_1 +v_2
In the forward path, this will be equivalent to:
+step +proj=push +v_1 +v_2
+step +proj=hgridshift +grids=foo
+step +proj=vgridshift +grids=bar
+step +prop=pop +v_1 +v_2
And similarly in the reverse path, this will be quivalent to:
+step +proj=push +v_1 +v_2
+step +proj=hgridshift +grids=foo
+step +inv +proj=vgridshift +grids=bar
+step +proj=pop +v_1 +v_2
|
|
|
|
faithful serialization of the geoid_geog_crs parameter of proj_create_vertical_crs_ex()
|
|
+geoidgrids and +vunits != m
|
|
|
|
|
|
in CRS name
|
|
|
|
This is invalid WKT, but GDAL 2.4 used to accept it and make a reasonable
use of it...
Currently we default it to 0 which is non sensical. Better use 1 as GDAL 2.4
did, and emit a warning.
Other fix: proj_create_from_wkt() was documented to operate by default in
non-strict validation mode, but it was actually in strict mode. So do as
documented.
|
|
|
|
https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=17923. master only
|
|
handling of +key=string_value parameters
|
|
Rename CS template argument, to avoid conflict with macro in Solaris system headers.
Similar to 2f8bd934860b135044c5122e3272f7cc41ba81e7
|
|
'+init=epsg:xxxx +no_defs' string (related to #1597)
|
|
(related to #1597)
|
|
+o_proj=longlat worked) (fixes #1601)
|
|
Use in API and utilities WKT2_2019 instead of WKT2_2018 (fixes #1578)
|
|
- 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.
|
|
(fixes #1574)
The exact circumstances are a bit difficult to explain, but they involve
using a non-default context, enabling proj_context_use_proj4_init_rules() on it,
using proj_create(ctxt, "+init=epsg:XXXX +type=crs"), whereas PROJ_LIB is
defined to a directory that has a 'epsg' file in it.
|
|
|
|
with longitudes outside of [-180,180]
|
|
+datum=NAD27 and +over, where the datum was just replaced by its ellipsoid
|
|
|
|
lowercase. This showed in MapServer use cases
|
|
database (fixes #1565)
|
|
to exported PROJJSON strings
|
|
|
|
ParametricCRS and TemporalCRS
|
|
Dynamic[Geodetic|Vertical]ReferenceFrame
|
|
Transformation and ConcatenatedOperation
|
|
|
|
|
|
|
|
|
|
|
|
WKT1 importer: do case insensitive comparison for axis direction
|
|
createFromUserInput(): support OGC URN to create projectedCRS, for example to instanciate a projected 3D CRS
|
|
Fixes https://github.com/OSGeo/gdal/issues/1623
http://portal.opengeospatial.org/files/?artifact_id=999 is not explicit if
string comparisons should be case sensitive or not, but WKT2 allows for case
differences in keyword and enumerated value, so follow this relaxed interpretation
for WKT1 as well.
|
|
to instanciate a projected 3D CRS
|
|
ID[] node
|
|
|
|
ETRS89 (EPSG:4937), make sure that the vgridshift is applied first (ie on Amersfoort datum) before the hgridshift
|