aboutsummaryrefslogtreecommitdiff
path: root/src/iso19111
AgeCommit message (Collapse)Author
2020-02-06Fix identification of ESRI-style datum names starting with D_ but without aliasEven Rouault
Fixes #1911
2020-02-06Fix 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-02-06Fix 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-23Merge pull request #1875 from ↵Even Rouault
rouault/backport_fix_wrong_use_of_derivingConversion [6.3 backport] 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-23Database: update to EPSG v9.8.6Even Rouault
Fixes #1867
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-11WKT1_GDAL export: limit datum name massaging to names matching EPSG (fixes ↵Even Rouault
#1835)
2020-01-11createOperations(): fix dealing with projected 3D CRS whose Z units != metreEven Rouault
2020-01-11CompoundCRS::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-02fix 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.
2019-12-10Database: update to IGNF v3.1.0Even Rouault
2019-12-09CRS identification: use case insensitive comparison for authority name ↵Even Rouault
(fixes #1779)
2019-12-05import from PROJ string CRS: better deal with strings that look like Google ↵Even Rouault
Mercator projection, but with subtlely different parameters (fixes https://github.com/OSGeo/gdal/issues/2087)
2019-12-03coordinateoperation.cpp: add nullptr checks to please CLang Static Analyzer ↵Even Rouault
that suddenly warns about them for unknown reason...
2019-12-03Database: register AUSGeoid09 and AUSGeoid2020Even Rouault
Related to https://github.com/OSGeo/proj-datumgrid/pull/66 Tune operation search so that it can work with Geog2D <--> VertCS for commandline niceness
2019-12-02Database: register the BWTA2017.gsb grid (DHDN->ETRS89 for Baden-Wurtemberg)Even Rouault
Relates to https://github.com/OSGeo/proj-datumgrid/pull/65 , https://github.com/OSGeo/proj-datumgrid/issues/22 As EPSG has no entry for it, we create a grid_transformation, as well as a dedicated area of use based on the extent of the grid, under the PROJ authority. With the hope to be able to remove it once EPSG has an entry...
2019-11-28createOperations(): fix vertical to geographic when synthetizing an ↵Even Rouault
operation that involves a vertical axis reversal
2019-11-28Attempt at fixing test failures due to ↵Even Rouault
8a5740637760f837c9145c72ad8080927a3a4bf0 in the no-grid scenario
2019-11-28createOperations(): if direct transformation is found in the database but ↵Even Rouault
not instantiable, allow using through intermediates. Should help in theory for Auckland 46 -> NZVD2016 the case but there are other issues
2019-11-28EPSG codes for YEAR and SECOND are interchanged. EPSG registry report ↵Martin Desruisseaux
EPSG::1040 for second and EPSG::1029 for year.
2019-11-26createOperations(): fix an exception in transformations between Projected3D ↵Even Rouault
CRS and Projected CRS
2019-11-26Merge pull request #1748 from rouault/improve_hgrid_vgrid_hgrid_inv_take2Even Rouault
Optimize pipelines involving horizontal shift grid, vertical shift grid, inverse horizontal shift grid (take 2)
2019-11-25Merge pull request #1745 from rouault/optimize_compound_to_geogKristian Evers
createOperations(): optimize compoundCRS to geogCRS, when the geogCRS of the compoundCRS is the same as the target geogCRS
2019-11-25Merge pull request #1737 from rouault/proj_create_derived_geographic_crsKristian Evers
Add proj_create_derived_geographic_crs() and proj_create_conversion_pole_rotation_grib_convention() to address GRIB datasets using a pole rotation method
2019-11-25Doc: change 7.0 references to 6.3Even Rouault
2019-11-25PROJStringFormatter::toString(): optimize hgridshift, vgridshift, hgridshift ↵Even Rouault
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.
2019-11-25Pipeline: support +omit_fwd and +omit_inv keywordsEven Rouault
Inspired from syntax of https://github.com/OSGeo/PROJ/pull/453/files but 'rebased' on top of previous commit that cleans up the pipeline implementation Different situations: - +omit_fwd: the step when followed in the forward path will be omitted the step when followed in the reverse path will be executed - +omit_fwd +inv: the step when followed in the forward path will be omitted the step when followed in the reverse path will be executed (with the inv method) - +omit_inv: the step when followed in the forward path will be executed the step when followed in the reverse path will be omitted - +omit_inv +inv: the step when followed in the forward path will be executed (with the inv method) the step when followed in the reverse path will be omitted This will be used in the next commit to optimize constructs like +step +proj=hgridshift +grids=foo +step +proj=vgridshift +grids=bar +step +inv +proj=hgridshift +grids=foo Such steps are used for CRS to CRS transformations where applying the vertical grid requires to do a transformation to an interpolating CRS. One can notice that in the last step will just restore the horizontal coordinates before the first step, so doing an inverse hgridshift is overkill. So that could be optimized 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 In the forward path, this will be equivalent to: +step +proj=push +v_1 +v_2 +step +proj=hgridshift +grids=foo +step +proj=vgridshift +grids=bar +step +prop=pop +v_1 +v_2 And similarly in the reverse path, this will be quivalent to: +step +proj=push +v_1 +v_2 +step +proj=hgridshift +grids=foo +step +inv +proj=vgridshift +grids=bar +step +proj=pop +v_1 +v_2
2019-11-25normalizeForVisualization() and other methods applying on a ProjectedCRS: do ↵Even Rouault
not mess the derivingConversion object of the original object (fixes #1736) normalizeForVisualization(), promoteTo3D(), demoteTo2D(), alterGeodeticCRS(), alterCSLinearUnit() and alterParametersLinearUnit() all used the object returned by derivingConversionRef() to create a new ProjectedCRS. While doing so, this caused the derivingConversion of the original object to have its targetCRS set to the object returned by normalizeForVisualization() and similar. If that object died, then the weak pointer would be reset, and the original ProjectedCRS() has now its derivingConversionRef()->targetCRS() nullptr So bottom line is use derivingConversion() for anything that is not pure reading !!! This is confirmed to be the fix for the QGIS scenario in https://github.com/qgis/QGIS/issues/30569#issuecomment-540060919 In QGIS use case, the issue arised when using a projected CRS with a non-GIS friendly axis (that is where normalizeForVisualization() created a new projectedCRS)
2019-11-25createOperations(): optimize compoundCRS to geogCRS, when the geogCRS of the ↵Even Rouault
compoundCRS is the same as the target geogCRS
2019-11-25CoordinateOperationFactory::Private::setCRSs(): fix potential issue with ↵Even Rouault
overriding CRS on a InverseCoordinateOperation (could be related to #1736)
2019-11-22Add proj_create_derived_geographic_crs() and ↵Even Rouault
proj_create_conversion_pole_rotation_grib_convention() to address GRIB datasets using a pole rotation method
2019-11-21Fix typos in code commentsEven Rouault
2019-11-19createOperations(): in some situations, consider when going from A to D ↵Even Rouault
intermediates B and C, such there's a A->B operation and C->D operation, and A and C are not exactly the same CRS but use the same geodetic datum
2019-11-18createFromCRSCodesWithIntermediates(): do not consider intermediate CRS ↵Even Rouault
whose datum has a publication date older than the source and target datums
generated by cgit v1.2.3 (git 2.25.1) at 2026-03-19 17:28:36 +0000