| Age | Commit message (Collapse) | Author |
|
Fixes https://github.com/qgis/QGIS/issues/37898
|
|
instead of +axis=swu (fixes #2299)
|
|
Projected3D CRS and not a compound CRS with a unknown datum (fixes #2287) (#2288)
|
|
TIMEUNIT is at the CS level, and not inside (#2276)
Adresses testTemporal() and testCompoundWithTime() cases of
https://github.com/OSGeo/PROJ/issues/2275#issuecomment-650765730
|
|
'Interrupted Googe Homolosine' (resp. 'Interrupted Googe Homolosine Ocean')
|
|
and non metre units (contributes to fixes #2232)
|
|
|
|
exporting it back as such (on the same object) (fixes #2228)
|
|
Fixes related to CompoundCRS and BoundCRS
|
|
component when vertical CRS has non metre unit (fixes #2217)
|
|
|
|
and handle +czech correctly (fixes #2199) (#2200)
* createFromProjString(): handle default parameters of '+krovak +type=crs', and handle +czech correctly (fixes #2199)
* Doc: add default values for Krovak
|
|
to 40466db40499e003cc59957d7e245b6ce8f8e4a3
|
|
Contributes to fixing issue raised in
https://lists.osgeo.org/pipermail/gdal-dev/2020-April/052003.html
|
|
looks like the one for WGS 84 / Pseudo Mercator (fixes https://github.com/OSGeo/gdal/issues/2433) (#2174)
|
|
|
|
* Allow importing EPSG:{horizontal_code}+{geographic_code} and
turn it into valid Geographic 3D or Projected 3D CRS internally
* Allow importing WKT1 COMPD_CS[] with above structure
* On an object imported that way, allow exporting to WKT1_GDAL,
with this non-standard structure of a horizontal CRS + geographic CRS
|
|
Map it to 'Lambert Cylindrical Equal Area' / EPSG:9835 non-spherical
method, when the ellipsoid is not a sphere. And rationalize the
handling of this for other methods with spherical vs non-spherical formulations
|
|
(refs https://github.com/OSGeo/gdal/issues/2392)
|
|
e.g. 'WGS 84 + EGM96 height'
|
|
https://github.com/OSGeo/gdal/issues/2347)
|
|
According to https://gis.stackexchange.com/questions/226679/complex-utm-projection
it is highly likely that Transverse_Mercator_Complex corresponds to our
extended/enhanced/Poder-Engsager transverse mercator method (etmerc), or something
similarly precise. So we can map that to the standard Transverse Mercator
method, since etmerc is used for it.
|
|
|
|
Transverse_Cylindrical_Equal_Area projections (#2020)
* Add mapping of ESRI projection methods Mercator_Variant_A, Mercator_Variant_C
and Transverse_Cylindrical_Equal_Area
* Add a few notes about missing mappings
|
|
|
|
|
|
Fixes #1881
Digging into the implementation of proj=cea, it appears that
k_0 and lat_ts are intended to be exclusive ways of specifying the
same concept. EPSG only models the variant using lat_s.
So if k_0 is found and lat_ts is absent, compute the equivalent
value of lat_ts from k_0.
Note: k_0 should normally be in the [0,1] range. In case creative users
would use something outside, we raise an exception, even if the cea
implementation could potentially deal with any k_0 value. Hopefully
this is a (reasonable) limitation that will address nominal use cases.
|
|
#1823)
|
|
|
|
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.
|