| Age | Commit message (Collapse) | Author |
|
createOperations(): optimize compoundCRS to geogCRS, when the geogCRS of the compoundCRS is the same as the target geogCRS
|
|
Add scripts/grid_checks.py
|
|
Add proj_create_derived_geographic_crs() and proj_create_conversion_pole_rotation_grib_convention() to address GRIB datasets using a pole rotation method
|
|
Change version numbers to 6.3.0
|
|
|
|
|
|
Little script used lately to check consistency of the database
regarding the grid_transformation vs grid_alternatives tables.
And also check the content of the database vs proj-datumgrid
to identify gaps.
|
|
Database: register Canadian provincial horizontal shift grids
|
|
Database: reference GDA94_GDA2020_conformal_christmas_island.gsb and …
|
|
normalizeForVisualization() and other methods applying on a ProjectedCRS: do not mess the derivingConversion object of the original object (fixes #1736)
|
|
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)
|
|
compoundCRS is the same as the target geogCRS
|
|
overriding CRS on a InverseCoordinateOperation (could be related to #1736)
|
|
|
|
GDA94_GDA2020_conformal_christmas_island.gsb
Related to https://github.com/OSGeo/proj-datumgrid/pull/62
|
|
proj-datumgrid
|
|
Counterpart of https://github.com/OSGeo/proj-datumgrid/pull/61
Fixes #202
|
|
locations that require TLS/SSL, however the ssl module in Python is not available.'
|
|
Doc: configure the 'Edit on GitHub' button
|
|
proj_create_conversion_pole_rotation_grib_convention() to address GRIB datasets using a pole rotation method
|
|
[ci skip]
|
|
|
|
|
|
about.rst
|
|
|
|
|
|
createOperations(): chain operations whose middle CRSs are not identical but have the same datum
|
|
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
|
|
whose datum has a publication date older than the source and target datums
|
|
|
|
Populated from realization_epoch column from EPSG
The 'publication_date' naming is from OGC Topic 2, and hasn't been yet adopted
by the EPSG dataset.
See http://docs.opengeospatial.org/as/18-005r4/18-005r4.html , Annex G, clause 11
and https://32zn56499nov99m251h4e9t8-wpengine.netdna-ssl.com/wp-content/uploads/2019/09/EPSG-relational-data-model-changes_2019-09-18.pdf
|
|
Affected parameters of Plate Motion Models.
Spotted by Xavier Collilieux on https://lists.osgeo.org/pipermail/proj/2019-November/009011.html
|
|
result through ITRF2008. Was broken in master by the addition of the 'WGS84 -> WGS 84 (Gxxx)' null operations in the PROJ authority
|
|
alternatives, to select the operation with best accuracy
|
|
intermediate CRS if we found direct transformation(s) but had to eliminate them due to other criteria
|
|
distinguish null transform from ballpark transform
|
|
createOperations(): remove the concept of geodetic_datum_preferred_hub
|
|
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.
|
|
operations that belong to different authorities. Should make the concept of geodetic_datum_preferred_hub introduced some time ago obsolete
|
|
|
|
|
|
correctly the geographic coordinates of the input coord when the CRS is not Greenwich based
|
|
rouault/better_export_proj_create_vertical_crs_ex_to_projjson
import/export PROJJSON: support a interpolation_crs key to geoid_model
|
|
faithful serialization of the geoid_geog_crs parameter of proj_create_vertical_crs_ex()
|
|
|
|
rouault/fix_createoperations_with_geoidgrids_and_non_metre_vunits
createOperations(): fix transformation computation from/to a CRS with +geoidgrids and +vunits != m
|
|
+geoidgrids and +vunits != m
|
|
|
|
Minor typo fix in docs faq.rst
|
|
|