aboutsummaryrefslogtreecommitdiff
path: root/src
AgeCommit message (Collapse)Author
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-25Change version numbers to 6.3.0Even Rouault
2019-11-25pipeline.cpp: use more explict variable namesEven 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-24pipeline.cpp: hopefully make code more readable by using more C++ goodness. ↵Even Rouault
No functional change intended (except a likely minor correction/improvement in get_next_non_whatever_unit in the PJ_INV case where the iteration should start at step-1)
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
2019-11-18createGeodeticDatum(): query and set publicationDateEven Rouault
2019-11-18createOperations(): fix so that GDA94 -> WGS 84 (G1762) still include a ↵Even Rouault
result through ITRF2008. Was broken in master by the addition of the 'WGS84 -> WGS 84 (Gxxx)' null operations in the PROJ authority
2019-11-18proj_trans(): tune selection of operation when there are several ↵Even Rouault
alternatives, to select the operation with best accuracy
2019-11-18createOperations(): small perf improvement. Do not attempt going through an ↵Even Rouault
intermediate CRS if we found direct transformation(s) but had to eliminate them due to other criteria
2019-11-18createOperations(): geocentric to geocentric operation synthetization: ↵Even Rouault
distinguish null transform from ballpark transform
2019-11-17createOperations(): remove the concept of geodetic_datum_preferred_hubEven Rouault
This was introduced in 63857c92b271bbcd10df0a032304982011acb2a9. Due to the fix done in the previous commit, we can mostly revert the above commit. We just keep the added tests and the custom WGS 84<-->WGS 84 (Gxxxx) null transformations.
2019-11-17findsOpsInRegistryWithIntermediate(): tune it to be able to research ↵Even Rouault
operations that belong to different authorities. Should make the concept of geodetic_datum_preferred_hub introduced some time ago obsolete
2019-11-17typo fix in comment [ci skip]Even Rouault
2019-11-16typo fix in comment [ci skip]Even Rouault
2019-11-16proj_create_crs_to_crs(): fix autoselection logic of operation to compute ↵Even Rouault
correctly the geographic coordinates of the input coord when the CRS is not Greenwich based
2019-11-14import/export PROJJSON: support a interpolation_crs key to geoid_model for ↵Even Rouault
faithful serialization of the geoid_geog_crs parameter of proj_create_vertical_crs_ex()
2019-11-14createOperations(): fix transformation computation from/to a CRS with ↵Even Rouault
+geoidgrids and +vunits != m
2019-11-14Code reformatEven Rouault
2019-11-12Fix proj_assign_context()/pj_set_ctx() with pipelines and alternative coord ↵Even Rouault
operations Fixes https://github.com/OSGeo/gdal/issues/1989 pj_set_ctx() only changes the context to the main object. It should also recurse down to the steps of the pipeline and the alternative coordinate operations hold in alternativeCoordinateOperations In the GDAL use case with multithreaded reprojection, and objects being transferred between thread, this would cause a failed coordinate transformation to affect an unrelated transformation of another thread...
2019-11-09Doc: document oddity related to identification of CRS from ESRI WKTEven Rouault
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.
2019-11-04proj_create_vertical_crs(): enhance docEven Rouault
2019-11-04Merge remote-tracking branch 'origin/master' into geoid_modelEven Rouault
2019-11-03createOperations(): in some circumstances we wrongly promoted a Helmert ↵Even Rouault
geog2D transformation to a geog3D Fixes for example EPSG:4979 to EPSG:2189, as raised in https://github.com/OSGeo/gdal/issues/1972#issuecomment-548814354
2019-11-03Import from WKT of VERT_CS: remove outdated EXTENSION.PROJ4_GRIDS for NAVD88Even Rouault
2019-11-03Import from WKT: add tweaks for Lidar WKT1 VERT_CS that embeds geoid model ↵Even Rouault
in CRS name
2019-11-02Merge pull request #1709 from rouault/improve_extent_filteringEven Rouault
Better filtering based on extent and performance improvements
2019-11-02Add a geoid_model name in database, use GEOIDMODEL for transformations, add ↵Even Rouault
a proj_create_vertical_crs_ex()
2019-11-02WKT and PROJJSON: add import/export of geoid model of VertCRSEven Rouault
2019-11-02Add tracing framework, and improve createOperations() performanceEven Rouault
2019-10-31Merge pull request #1703 from ↵Even Rouault
rouault/improve_transformation_with_alternative_vertical_unit_and_direction Improve transformations with alternative vertical unit and direction
2019-10-30createOperations(): try to recover extent of CRS from the database when they ↵Even Rouault
are missing, especially for compound CRS. Helps having shorter/more relevant results
2019-10-30createOperations() filtering: code changes regarding extent handling. No ↵Even Rouault
functional changes
2019-10-30createFromWkt(): be tolerant to missing scale_factor parameter (fixes #1700)Even Rouault
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.
2019-10-30Rework importing of Vertical unit change from EPSG db, add support for ↵Even Rouault
Height Depth Reversal and use it in createOperations()
2019-10-29Vertical transformations: improve situations similar to transforming from ↵Even Rouault
'NAVD88 (ftUS)' to X, where we now consider the available transformations from 'NAVD88' to X that might exist in the database
2019-10-29createOperations(): split gigantic method into many smaller ones. No ↵Even Rouault
functional change expected
2019-10-29Little tweaks in implicit 2D/3D geog conversions in compoundCRS to geogCRS ↵Even Rouault
transformations
2019-10-28createOperations(): avoid infinite recursion in a super weird case. Fixes ↵Even Rouault
https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=18587
2019-10-28ReformatEven Rouault
generated by cgit v1.2.3 (git 2.25.1) at 2026-04-26 13:38:38 +0000