| Age | Commit message (Collapse) | Author |
|
accuracy, or derive it from the grid name if it is known
|
|
|
|
|
|
|
|
ENH: Added temporal, engineering, and parametric datum PJ_TYPE enumerations
|
|
Found when investigating https://github.com/OSGeo/gdal/issues/2744
but the root cause of the GDAL issue is different.
|
|
|
|
|
|
(#2269)
Closes #2268
|
|
|
|
ProjectedCRS::identify(): fix identification of EPSG:3059 (fixes #2214)
|
|
'LKS92_Latvia_TM' name, and other cleanups/improvements (fixes #2214)
|
|
|
|
|
|
e.g. 'WGS 84 + EGM96 height'
|
|
proj_create_crs_to_crs_from_pj()
|
|
area of use
|
|
|
|
Return the index of the operation that would be the most appropriate to
transform the specified coordinates.
This operation may use resources that are not locally available, depending
on the search criteria used by proj_create_operations().
This could be done by using proj_create_operations() with a punctual bounding
box, but this function is faster when one needs to evaluate on many points
with the same (source_crs, target_crs) tuple.
|
|
|
|
|
|
|
|
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()
|
|
This commit is the result of the squashing of rfc4_dev branch in a single
commit. It implements mostly RFC 4 related work.
* Grid handling:
- remove obsolete and presumably unfinished implementation of grid catalog functionality
- all grid functionality is in grids.cpp/.hpp
- vertical and horizontal grid shift: rework to no longer load whole grid into memory
- remove hgrids and vgrids member from PJ structure, and store them in hgridshift/vgridshift/deformation structures
- build systems: add optional libtiff dependency. Must be explicitly disabled if not desired
- add support for horizontal and vertical grids in GeoTIFF, if libtiff is available
- add GenericShiftGridSet and GenericShiftGrid classes, relying on TIFF grids, that can be used for generic purpose grid-based adjustment
- add a +proj=xyzgridshift method to perform geocentric translation by grid. Used for French NTF to RGF93 transformation using gr3df97a.tif grid
- deformation: add support for +grids= for GeoTIFF grids
- horizontal grid shift: fix failures on points slightly outside a subgrid (fixes #209)
* File management:
- add a filemanager.cpp/.hpp to deal with file related work
- test for legacy proj_api.h fileapi
- proj.h: add proj_context_set_fileapi() and proj_context_set_sqlite3_vfs_name() (fixes #866)
- add capability to read resource files from the user writable directory
* Network access:
- build systems: add optional curl dependency
- add a curl-based default implementation for network related functionality
- proj.h: add C API to control network functionality, and optionaly provide network callbacks
- add data/proj.ini with default settings
- add a SQLite3 local cache of downloaded chunks
- add proj_is_download_needed() and proj_download_file()
* Use Win32 Unicode APIs and expect all strings to be UTF-8 (fixes #1765)
For backward compatibility, if PROJ_LIB content is found to be not UTF-8 or
pointing to a non existing directory, then an attempt at interpretating it
in the ANSI page encoding is done.
proj_context_set_search_paths() now assumes strings to be in UTF-8, and
functions returning paths will also return values in UTF-8.
|
|
|
|
#1823)
|
|
|
|
|
|
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
|