| Age | Commit message (Collapse) | Author |
|
Hopefully final cut at solving the same class of bug that the one
that affected QGIS in December.
This time, this hit GDAL in the situation of
https://lists.osgeo.org/pipermail/gdal-dev/2020-January/051500.html
The bug fix for that particular issue is in
PROJStringParser::createFromPROJString()
But grepping more in the code base, I could find other potential smelly
situations (might not be issues, but better be safe than sorry),
so let's fix them too.
Bottom line is:
derivingConversionRef() should *only* be used for consultation, and
never to create a new ProjectedCRS()
|
|
|
|
|
|
Add proj_create_derived_geographic_crs() and proj_create_conversion_pole_rotation_grib_convention() to address GRIB datasets using a pole rotation method
|
|
|
|
proj_create_conversion_pole_rotation_grib_convention() to address GRIB datasets using a pole rotation method
|
|
alternatives, to select the operation with best accuracy
|
|
|
|
faithful serialization of the geoid_geog_crs parameter of proj_create_vertical_crs_ex()
|
|
|
|
Or more generally formulations that don't have an explicit axis order.
Refs https://github.com/pyproj4/pyproj/issues/475
projinfo 'GEOGCS["GCS_WGS_1984",DATUM["D_WGS_1984",SPHEROID["WGS_1984",6378137.0,298.257223563]],PRIMEM["Greenwich",0.0],UNIT["Degree",0.0174532925199433]]'
returns EPSG:4326 with 100% confidence.
But its axis order is not the same as EPSG:4326.
I've pondered about this, like decreasing the confidence of the match,
but this would have downstream effects on GDAL (shapefiles with the
above content in a .prj would no longer be identified as EPSG:4326).
So for now, document that oddity.
|
|
|
|
|
|
a proj_create_vertical_crs_ex()
|
|
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.
|
|
In recent commits, we added a generalize_proj_crs_create_bound_vertical_crs_to_WGS84()
function, but there are situations where more accurate results can be obtained, if
instead of specifying WGS84 as the hub CRS, the user can specify the exact hub CRS.
For example the GEOID2018 grid is against NAD83(2011).
So replace this function with proj_crs_create_bound_vertical_crs()
|
|
approximate as WKT1 that doesn't support it
|
|
|
|
Relates to https://github.com/OSGeo/gdal/issues/1856
|
|
createOperations(), and test it (fixes #1623)
|
|
|
|
proj_crs_create_projected_3D_crs_from_2D() (fixes #1587)
Also add a --3d switch to projinfo
|
|
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.
|
|
has_ballpark_transformation
|
|
|
|
database (fixes #1565)
|
|
Add CRS JSON export (refs #1545)
|
|
to exported PROJJSON strings
|
|
|
|
Closes #1519
|
|
proj_concatoperation_get_step()
|
|
- 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()
|
|
metadata from a grid filename
|
|
|
|
|
|
alternatives
|
|
|
|
|
|
|
|
Add no-op operation. It does nothing.
|
|
|
|
Fixes #1301
This function takes the output PJ from proj_create_crs_to_crs(),
and add (or undo) the needed axis swap operations so that the
object returned by proj_normalize_for_visualization() has the usual
GIS axis order.
In this implementation, this does something only if the coordinate
system of the source or target CRS, geographic or projected, has
NORTH, EAST ordering.
CompoundCRS wrapping those objects are also handled.
|
|
|
|
|
|
|
|
used to know if it includes a very approximative transformation term
|
|
there is no direct transformation
|
|
PJ object returned by proj_create_crs_to_crs() when there are several alternatives
|
|
* 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>
|