| Age | Commit message (Collapse) | Author |
|---|
|
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
|
|
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)
|
|
|
|
proj-datumgrid
|
|
locations that require TLS/SSL, however the ssl module in Python is not available.'
|
|
Doc: configure the 'Edit on GitHub' button
|
|
[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
|
|
|
|
Fix proj_assign_context()/pj_set_ctx() with pipelines and alternative coord operations
|
|
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...
|
|
Database: update to EPSG v9.8.4
|
|
|
|
Doc: document oddity related to identification of CRS from ESRI WKT
|
|
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.
|
|
Build: require SQLite 3.11 (refs #1718)
|
|
|
|
|
|
PROJ can build and run against older version (3.7 for example), but it has
been found that performance is horrible. With 3.11 (Ubuntu 16.04), it is
fine, so sets this as the minimum version.
|
|
updated docker URLs and added Fedora entry
|
|
|
|
|
|
Add support for GEOIDMODEL
|
