| Age | Commit message (Collapse) | Author |
|
Non-trivial updates:
- some vertical CRS are now encoded as DerivedVerticalCRS. e.g EPSG:8228
"NAVD88 height (ft)", with base EPSG:5703 "NAVD88 height". As we don't
have support in our PROJ db model for DerivedVerticalCRS, modify the
import script to 'resolve' the derivation up to the original datum.
- Method EPSG:1069 'Change of Vertical Unit' is no longer used. It is
replaced by a generic-purpose EPSG:1104 method that doesn't take any
conversion factor. And generic conversions EPSG:7812 and EPSG:7813 are
now used in concatenated operations, which require code changes as
well.
|
|
|
|
PROJ_SPATIAL_CRITERION_PARTIAL_INTERSECTION if area is specified"
This reverts commit ebe3425bf66287e004958eb53976d3837f88b9e1.
It was found to break gdalwarp usage in
https://github.com/OSGeo/gdal/issues/3695 when passing a bbox that is
quite large.
|
|
createFromUserInput(): change name of CRS built from URN combined references to match the convention of EPSG projected CRS
|
|
createOperations(): fix Geog to Geog when one is deprecated (fix master regression)
|
|
to match the convention of EPSG projected CRS
|
|
regression)
|
|
Closes #2667
|
|
ESRI:103668+EPSG:5703 (#2669)
|
|
proj_get_crs_info_list_from_database() filter on and return celestial body name
|
|
CRS::normalizeForVisualization(): propagate domains/extent of original CRS (fixes #2603)
|
|
(fixes #2603)
|
|
|
|
|
|
|
|
syntax
|
|
syntax
|
|
|
|
e.g:
http://www.opengis.net/def/crs/EPSG/0/4326
http://www.opengis.net/def/crs-compound?1=http://www.opengis.net/def/crs/EPSG/0/4326&2=http://www.opengis.net/def/crs/EPSG/0/3855
|
|
createBetweenGeodeticCRSWithDatumBasedIntermediates() reachable...
... and optimize its execution time by rewriting it completely.
This code path was no longer triggered in tests since EPSG got a direct
transformation for GDA94 to WGS 84 (G1762).
|
|
+hyperbolic
|
|
|
|
Issue spotted by GDAL autotest suite.
|
|
(fixes #2588)
when the source and target CRS share the same geog CRS, but the interpolation
CRS of the vertical transformation isn't the same, and a Helmert
transformation exists between them...
For example, for "CH1903+ + EGM96" to CH1903+ 3D where the interpolation
CRS is WGS84.
|
|
|
|
methods and params lacking an explicit EPSG id
|
|
Add capability to get SQL statements to add custom CRS in the database
|
|
proj.h: add PROJ_COMPUTE_VERSION, PROJ_VERSION_NUMBER, PROJ_AT_LEAST_VERSION macros
|
|
be returned by proj_create_crs_to_crs()
|
|
macros
Makes it easier for users to test if they build against a PROJ version
later than a given x.y.z version.
|
|
auxiliary DB
|
|
|
|
|
|
for intermediate objects
|
|
|
|
Make proj_lp_dist() and proj_geod() work on a PJ* CRS object
|
|
|
|
in sqlite >= 3.11
|
|
|
|
|
|
RGF93 and CH1903+ (fixes #2541)
|
|
|
|
https://github.com/OSGeo/PROJ/pull/2536 changed the name of the
ellps=intl to "International 1924 (Hayford 1909, 1910)"
When writing a GeoTIFF file from GDAL using a SRS built from a
PROJ string, GDAL massages the datum name to
"Unknown_based_on_International_1924_Hayford_1909_1910_ellipsoid"
Before this fix, this wasn't considered as equivaleent to the non-massaged
datum name "Unknown based on International 1924 (Hayford 1909, 1910) ellipsoid"
|
|
Closes #2515
|
|
Allow a BoundCRS to use a PROJ string transformation
|
|
|
|
Related to https://lists.osgeo.org/pipermail/proj/2021-February/010040.html
Given test.wkt with
```
BOUNDCRS[
SOURCECRS[
GEOGCRS["unknown",
DATUM["Unknown based on GRS80 ellipsoid",
ELLIPSOID["GRS 1980",6378137,298.257222101,
LENGTHUNIT["metre",1],
ID["EPSG",7019]]],
PRIMEM["Greenwich",0,
ANGLEUNIT["degree",0.0174532925199433],
ID["EPSG",8901]],
CS[ellipsoidal,2],
AXIS["longitude",east,
ORDER[1],
ANGLEUNIT["degree",0.0174532925199433,
ID["EPSG",9122]]],
AXIS["latitude",north,
ORDER[2],
ANGLEUNIT["degree",0.0174532925199433,
ID["EPSG",9122]]]]],
TARGETCRS[
GEOGCRS["WGS 84",
DATUM["World Geodetic System 1984",
ELLIPSOID["WGS 84",6378137,298.257223563,
LENGTHUNIT["metre",1]]],
PRIMEM["Greenwich",0,
ANGLEUNIT["degree",0.0174532925199433]],
CS[ellipsoidal,2],
AXIS["latitude",north,
ORDER[1],
ANGLEUNIT["degree",0.0174532925199433]],
AXIS["longitude",east,
ORDER[2],
ANGLEUNIT["degree",0.0174532925199433]],
ID["EPSG",4326]]],
ABRIDGEDTRANSFORMATION["Transformation from unknown to WGS84",
METHOD["PROJ-based operation method: +proj=pipeline +step +proj=unitconvert +xy_in=deg +xy_out=rad +step +proj=axisswap +order=2,1 +step +proj=cart +ellps=GRS80 +step +proj=helmert +convention=coordinate_frame +exact +step +inv +proj=cart +ellps=WGS84 +step +proj=axisswap +order=2,1 +step +proj=unitconvert +xy_in=rad +xy_out=deg"]]]
```
``projinfo -s @test.wkt -t "WGS 84" -o PROJ -q``
outputs:
```
+proj=pipeline
+step +proj=unitconvert +xy_in=deg +xy_out=rad
+step +proj=axisswap +order=2,1
+step +proj=cart +ellps=GRS80
+step +proj=helmert +convention=coordinate_frame +exact
+step +inv +proj=cart +ellps=WGS84
+step +proj=axisswap +order=2,1
+step +proj=unitconvert +xy_in=rad +xy_out=deg
```
|
|
|
|
|
|
Database: update to EPSG v10.011
|