| Age | Commit message (Collapse) | Author |
|
https://github.com/OSGeo/proj-datumgrid/pull/73
|
|
Database: register AT_GIS_GRID.gsb
|
|
https://github.com/OSGeo/proj-datumgrid/pull/72
|
|
Database: register AUSGeoid09 and AUSGeoid2020
|
|
that suddenly warns about them for unknown reason...
|
|
Related to https://github.com/OSGeo/proj-datumgrid/pull/66
Tune operation search so that it can work with Geog2D <--> VertCS for commandline
niceness
|
|
Database: register the BWTA2017.gsb grid (DHDN->ETRS89 for Baden-Wurtemberg)
|
|
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...
|
|
This PR is Windows only. It adds the directory ``.....\bin\..\share\proj``, where ``....\bin`` is the directory hosting ``proj.dll``, to the list of places where ``proj.db`` is searched. In addition to what happens at build time, this PR ads also the ability to do that at run-time. This means that a structure like
....\bin\proj.exe, proj.dll, ...
....\share\proj\proj.db, ...
will still find proj.db without needing to set the PROJ_LIB environment variable
|
|
Database: update ESRI entries with ArcGIS Desktop version 10.8.0 database
|
|
|
|
|
|
Update README, install.rst and resource_files.rst
|
|
Doc: clarifications regarding grid packages (fixes #1751)
|
|
- Content partly borrowed from @kbevers ' suggestions of
https://github.com/OSGeo/PROJ/issues/1751#issuecomment-558976968
- Remove mention about Swiss grids. Included in the europe package
- Remove section about HARN / HPGN grids. Those have been included
in the north-america package, and there is no longer any point in
mentionning the particularities of how ancient ones had to be
used with PROJ.4
- Remove section about obsolete proj_defs.dat
|
|
|
|
operation that involves a vertical axis reversal
|
|
8a5740637760f837c9145c72ad8080927a3a4bf0 in the no-grid scenario
|
|
PROJ is now a proper OSGeo project, let's advertise it as such!
|
|
not instantiable, allow using through intermediates. Should help in theory for Auckland 46 -> NZVD2016 the case but there are other issues
|
|
EPSG codes for YEAR and SECOND are interchanged
|
|
EPSG::1040 for second and EPSG::1029 for year.
|
|
CRS and Projected CRS
|
|
Optimize pipelines involving horizontal shift grid, vertical shift grid, inverse horizontal shift grid (take 2)
|
|
|
|
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.
|
|
|
|
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.
|
|
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
|
|
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)
|
|
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)
|
|
|
|
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]
|