| Age | Commit message (Collapse) | Author |
|
fix exporting CoordinateSystem to PROJ JSON with ID
|
|
|
|
Make EPSG:102100 resolve to ESRI:102100 (fixes #1730)
|
|
omit_fwd/omit_inv
|
|
https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=19367
|
|
|
|
Mercator projection, but with subtlely different parameters (fixes https://github.com/OSGeo/gdal/issues/2087)
|
|
Optimize pipelines involving horizontal shift grid, vertical shift grid, inverse horizontal shift grid (take 2)
|
|
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.
|
|
compoundCRS is the same as the target geogCRS
|
|
faithful serialization of the geoid_geog_crs parameter of proj_create_vertical_crs_ex()
|
|
|
|
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
|
|
'+init=epsg:xxxx +no_defs' string (related to #1597)
|
|
(related to #1597)
|
|
+o_proj=longlat worked) (fixes #1601)
|
|
- 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.
|
|
|
|
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
|
|
Reduce database size
|
|
from their components
Support following syntaxes:
- OGC URN combining references for compoundCRS:
e.g. "urn:ogc:def:crs,crs:EPSG::2393,crs:EPSG::5717"
- its GDAL shortcut: e.g. "EPSG:2393+5717"
- OGC URN combining references for concatenated operations:
e.g. "urn:ogc:def:coordinateOperation,coordinateOperation:EPSG::3895,coordinateOperation:EPSG::1618"
|
|
|
|
Fixes https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=14055
Credit to OSS Fuzz
|
|
|
|
This is a particular logic allowed by paragraph 7.3.3 Identifier
of OGC 18-010r6
|
|
This is the standard logic, that is now possible since ID is
allowed in BASEGEOGCRS and similar node
|
|
- Allow ID[] in base CRS of Derived CRS
- Allow VERSION[] in non-conversion coordinate operations
- Use VERSION[] to set operationVersion member of CoordinateOperation
- Export operationVersion in WKT2:2018
|
|
Relax tolerances in a few unit test, and in laea code.
Seen with gcc 5.3 and also 7.1
Related to the use of the 387 floating-point math, since they
disappear with gcc 7.1 if using non-default -mfpmath=sse -msse
|
|
|
|
from +proj=helmert/molodensky since there are ambiguities
|
|
* 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>
|
|
https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=12854. Credit to OSS Fuzz
|
|
https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=12837. Credit to OSS Fuzz
|
|
only to avoid breaking other use cases
|
|
Update ds to be in correspondence with ITRF2000 file
|
|
Coordinate operation computation with boundcrs / wktext: drop useless early bindins terms in generated pipeline (fixes #1232)
|