aboutsummaryrefslogtreecommitdiff
path: root/src/iso19111
AgeCommit message (Collapse)Author
2020-02-29createOperations(): fix wrong pipeline generation with CRS that has ↵Even Rouault
+nadgrids= and +pm= (#1998) Fixes issue reported at https://lists.osgeo.org/pipermail/gdal-dev/2020-February/051749.html The generated pipeline assumes that the input coordinates for the grid transformation were related to the non-Greenwich based datum, so we must compensate for that and add logic to go back to Greenwich.
2020-02-27Fix warnings of latest cppcheck masterEven Rouault
2020-02-26Database: register 4 height Austrian grids from ↵Even Rouault
https://github.com/OSGeo/PROJ-data/pull/13 + handle 'Vertical Offset by Grid Interpolation (BEV AT)' method
2020-02-25createOperations(): be robust to a GeographicCRS having a wrong ID attached ↵Even Rouault
to it (fixes #1982)
2020-02-25CompoundCRS::create(): reject combinations of components not allowed by ISO ↵Even Rouault
19111
2020-02-24createOperations(): keep height/z value in Helmert transform between 3D CRSEven Rouault
This is the consequence of a private email thread between me, Joel Haasdyk and Roger Lott. I initially raised that the GDA2020 technical manual advertized the Helmert transformation between GDA94 to GDA2020 to be a 3D one, with example of a test point where ellipsoidal heights where modified. It appears this was intended. The corresponding record in EPSG uses the EPSG:9607 "Coordinate Frame rotation (geog2D domain)" method between the 2D geographic CRS of GDA94 and GDA2020. From the email exchange, it appears that there's a lot of legacy explaining that Helmert transformations are registered only between 2D CRS, which doesn't mean that when applied to the corresponding 3D CRS, the change in ellipsoidal height should be discarded. Related to that, the EPSG database, while it has methods flagged "(geog3D domain)" never uses them. So... this changeset slightly ammends PROJ behaviour to ignore the "(geog2D domain)" flag, but only consider the dimensionality of the source & target CRS. However, for a EPSG transformation, those are always 2D CRS, hence introduce the use3DHelmert_ hack when we know that ultimately the 'real' source & target CRS are 3D. I wouldn't be surprised if in more complex pipeline the above logic would be lacking. But it fixes at least simple transformations.
2020-02-24Expose proj_context_is_network_enabled() in C APIEven Rouault
2020-02-19validateParameters(): fix false-positive warning on Equidistant CylindricalEven Rouault
We required the 'Latitude of natural origin' parameter to be present, but it is only a GDAL/PROJ specific thing, not a EPSG one.
2020-02-19DatabaseContext::lookForGridInfo(): use also old_proj_grid_name for lookups ↵Even Rouault
(fixes #1942)
2020-02-10PROJStringParser::Private::buildProjectedCRS(): avoid (harmless) division by ↵Even Rouault
zero in super odd case with corrupted PROJ string. Fixes https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=20624
2020-02-06Merge pull request #1915 from rouault/fix_1911Even Rouault
Fix identification of ESRI-style datum names starting with D_ but without alias
2020-02-05Fix identification of ESRI-style datum names starting with D_ but without aliasEven Rouault
Fixes #1911
2020-02-05Fix performance issue, affecting projinfo EPSG:7842Even Rouault
Fixes #1913 AuthorityFactory::createBetweenGeodeticCRSWithDatumBasedIntermediates() issued a complex SQL query that pushes the SQLite3 query plan optimizer to its limits. Was working reasonably with sqlite 3.11, but not with later versions. So put less constraints in the main query and do post-processing checks and auxiliary requests to avoid such issues. For some unknown reason, this slightly slows down a bit execution time of the whole test_cpp_api binary (~ 10%), but couldn't come with something better, despite trying many variations of the main SQL query. It seems that in the general case the non-filter LEFT JOIN on the supersession table helped, except on this EPSG:7842 case.
2020-01-29Add EPSG records for 'Geocentric translation by Grid Interpolation (IGN)' ↵Even Rouault
(gr3df97a.txt) and map them to new +proj=xyzgridshift
2020-01-29Merge pull request #1891 from rouault/rfc5Even Rouault
Implement RFC5: Adopt GeoTIFF-based grids for grids delivered with PROJ
2020-01-26Conversion::_exportToPROJString(): use const ref as rightly suggest by cppcheckEven Rouault
2020-01-26Make JSONParser::buildObjectDomain() staticEven Rouault
2020-01-26buildProjectionStandard(): make it obvious to cppcheck that null-ptr ↵Even Rouault
dereference cannot happen
2020-01-25Fix ingestion of +proj=cea with +k_0Even Rouault
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.
2020-01-25Implement RFC 5Even Rouault
2020-01-24createObjectsFromName(): use alias as fallback onlyEven Rouault
Fixes a regression of 6.3.0 found when creating with GDAL a TIFF with a Geographic3D CRS. As TIFF must also encode the Geographic2D CRS, the code of the Geographic2D CRS is searched from the name of the Geographic3D CRS. When doing createObjectsFromName( "ETRS89", {AuthorityFactory::ObjectType::GEOGRAPHIC_2D_CRS}, false, 1), the result returned was not EPSG:4258 as expected, but EPSG:4173 IRENET95 which is registered as an alias of ETRS89. So sort results such that non-alias results are returned first.
2020-01-23Merge pull request #1873 from rouault/fix_wrong_use_of_derivingConversionKristian Evers
Fix wrong use of derivingConversionRef() that caused GDAL bug
2020-01-23Fix wrong use of derivingConversionRef() that caused GDAL bugEven Rouault
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()
2020-01-23Database: add a geoid_like value for proj_method column of ↵Even Rouault
grid_alternatives, fix related entries and simplify/robustify logic to deal with EPSG 'Geographic3D to GravityRelatedHeight' methods
2020-01-22Database: update to EPSG v9.8.6Even Rouault
Fixes #1867
2020-01-22Merge RFC4 (#1865)Even Rouault
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.
2020-01-21ProjectedCRS::identify(): fix wrong identification of some ESRI WKT linked ↵Even Rouault
to units Fixes bug reported in https://lists.osgeo.org/pipermail/gdal-dev/2020-January/051481.html
2020-01-11Merge pull request #1838 from rouault/limit_datum_name_massaging_wkt1Even Rouault
WKT1_GDAL export: limit datum name massaging to names matching EPSG (fixes #1835)
2020-01-11Merge pull request #1836 from rouault/fix_projcrs3D_with_non_metre_z_unitEven Rouault
createOperations(): fix dealing with projected 3D CRS whose Z units != metre
2020-01-11WKT1_GDAL export: limit datum name massaging to names matching EPSG (fixes ↵Even Rouault
#1835)
2020-01-10CompoundCRS::identify(): avoid exception when horiz/vertical part is a BoundCRSEven Rouault
The exception only affects C++ users. It was caught by the C layer.
2020-01-10createOperations(): fix dealing with projected 3D CRS whose Z units != metreEven Rouault
2020-01-10Doc of CRS::identify(): make it clear that this is a best-effort attempt onlyEven Rouault
2020-01-07createObjectsFromName(): make it look up in the alias_name table too (fixes ↵Even Rouault
#1823)
2020-01-02Merge pull request #1820 from snowman2/cs_projjsonEven Rouault
fix exporting CoordinateSystem to PROJ JSON with ID
2020-01-01fix exporting CoordinateSystem to PROJ JSON with IDsnowman2
2019-12-20test: transformation_NZLVD_to_PROJ_string: attach database context to get ↵Even Rouault
filename substitution
2019-12-20Adding support for NZLVD vertical height transformationChris Crook
2019-12-17Merge pull request #1803 from ↵Even Rouault
rouault/improve_identification_with_datum_name_aliases identify(): take into datum name aliases (fixes #1800)
2019-12-16Merge pull request #1802 from rouault/improve_boundcrs_identifyEven Rouault
BoundCRS::identify(): improvements to discard CRS that aren't relevant (fixes #1801)
2019-12-16identify(): take into datum name aliases (fixes #1800)Even Rouault
2019-12-16Merge pull request #1786 from rouault/fake_EPSG_102100Kristian Evers
Make EPSG:102100 resolve to ESRI:102100 (fixes #1730)
2019-12-16BoundCRS::identify(): improvements to discard CRS that aren't relevant ↵Even Rouault
(fixes #1801) Fix for ``` projinfo --identify "+proj=utm +zone=48 +a=6377276.345 +b=6356075.41314024 +towgs84=198,881,317,0,0,0,0 +units=m +no_defs +type=crs" ``` to only return BoundCRS of EPSG:3148: 70 % Previously it also returned EPSG:23948 and EPSG:24048 whose projected CRS-only parts where likely matches, but those 2 CRSs don't have a +towgs84=198,881,317,0,0,0,0, so discard them.
2019-12-14Add proj_coordoperation_create_inverse to C API (#1795)Nyall Dawson
2019-12-13Fix compilation breakage of previous commit with some compilersEven Rouault
2019-12-13normalizeForVisualization(): address EPSG:32661 "WGS 84 / UPS North (N,E)" ↵Even Rouault
and EPSG:32761 "WGS 84 / UPS South (N,E)" Fixes https://github.com/qgis/QGIS/issues/33077
2019-12-13PROJStringFormatter: make startInversion/stopInversion properly deal with ↵Even Rouault
omit_fwd/omit_inv
2019-12-13WKTParser: fix assertion that can trigger on corrupted input. Fixes ↵Even Rouault
https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=19367
2019-12-11Make EPSG:102100 resolve to ESRI:102100 (fixes #1730)Even Rouault
2019-12-11createOperations(): make filtering out of 'uninteresting' operations less ↵Even Rouault
aggressive (refs #1787) 'EPSG:1304, Indian 1975 to WGS 84 (2), 5.0 m, Thailand - onshore and Gulf of Thailand' was removed because considered useless w.r.t first result 'EPSG:1812, Indian 1975 to WGS 84 (4), 3.0 m, Thailand - onshore' However the name of the area of use is not completely the same, so might be worth keeping it.
generated by cgit v1.2.3 (git 2.25.1) at 2026-02-27 22:24:30 +0000