| Age | Commit message (Collapse) | Author |
|
Add mapping of ESRI Equal_Area projection method to EPSG (fixes #2610)
|
|
|
|
|
|
|
|
|
|
|
|
WKT1:GDAL/ESRI when GEOGCS UNIT != Degree; morph to ESRI the PRIMEM name on export
|
|
fix parsing of a ProjectedCRS whose base is a Geocentric CRS
|
|
projected CRS
|
|
- WKT2 grammar: accept PARAMETER[name,value,id] without unit
- Recognize "Ellipsoid scaling factor" as a parameter with a scaling unit,
and defaults to Unity when not specified
- WKT2 parsing: implement the requirement of 18-010r7.html#80, that is
when a map projection parameter has no explicit unit, use metre/degree/unity
as the default unit (contrary to WKT1 parsing rules where they are deduced
from the GeogCRS angular unit and coordinate system)
|
|
|
|
find a corresponding ellipsoidal vertical datum
|
|
ellipsoidal height is found
|
|
GEOGCS[...],VERTCS[...]
|
|
ellipsoidal heights
|
|
"PROJCS[...],VERTCS[...]"
|
|
export to WKT1:ESRI
|
|
sphere (fixes GDAL PDS4 tests)
|
|
This is a peculiarity of the WKT grammar. Despite ISO 19111 saying that the
prime meridian is a component of the datum, in WKT, they are placed at the
same level, for backward compatibility with earlier WKT versions. So handle
exporting and importing that. The fix is only for situation where DATUM is
the top level object (was working fine otherwise), which is a uncommon use
case. And to limit the amount of issue, on export emit the prime meridian only
if it is not Greenwich.
|
|
- Map ESRI 'Local' to +proj=ortho when Scale_Factor = 1 and Azimuth = 0
- Map ESRI 'Orthographic' to a PROJ WKT2 'Orthographic (Spherical)'
which maps to +proj=ortho +f=0 to froce spherical evaluation
|
|
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
|