| Age | Commit message (Collapse) | Author |
|
Co-Authored-By: Kristian Evers <kristianevers@gmail.com>
|
|
Co-Authored-By: Kristian Evers <kristianevers@gmail.com>
|
|
Co-Authored-By: Kristian Evers <kristianevers@gmail.com>
|
|
Co-Authored-By: Kristian Evers <kristianevers@gmail.com>
|
|
|
|
Co-Authored-By: Kristian Evers <kristianevers@gmail.com>
|
|
Co-Authored-By: Kristian Evers <kristianevers@gmail.com>
|
|
Co-Authored-By: Kristian Evers <kristianevers@gmail.com>
|
|
Co-Authored-By: Kristian Evers <kristianevers@gmail.com>
|
|
Co-Authored-By: Kristian Evers <kristianevers@gmail.com>
|
|
Co-Authored-By: Kristian Evers <kristianevers@gmail.com>
|
|
Co-Authored-By: Kristian Evers <kristianevers@gmail.com>
|
|
Co-Authored-By: Kristian Evers <kristianevers@gmail.com>
|
|
Co-Authored-By: Kristian Evers <kristianevers@gmail.com>
|
|
Co-Authored-By: Kristian Evers <kristianevers@gmail.com>
|
|
Co-Authored-By: Kristian Evers <kristianevers@gmail.com>
|
|
Co-Authored-By: Kristian Evers <kristianevers@gmail.com>
|
|
Co-Authored-By: Kristian Evers <kristianevers@gmail.com>
|
|
Co-Authored-By: Kristian Evers <kristianevers@gmail.com>
|
|
createOperations()
|
|
|
|
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
|