| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
Add transformations for GGM10, Mexican geoid model
|
|
|
|
|
|
|
|
Update database layout version number to 1.2 consequently
This new capability will be used by IAU planetary CRS (refs #2601)
|
|
This seriously impacts French CRS users with the introduction of new
datums, geodetic CRS and projected CRS based on "RGF 93 v2" and "RGF 93 v2b",
and the previous single "RGF 93" being renamed as "RGF 93 v1".
To be noted too, the addition of a null transformation between NAD83(2011)
and WGS 84, which impacts a number of tests in the test suite.
|
|
|
|
|
|
|
|
|
|
|
|
* Add a PROJ_DATA.VERSION in proj.db to indicate the target PROJ-data
package version
* Make projsync use that information and the version_added and
version_removed properties added in https://github.com/OSGeo/PROJ-data/pull/67
to filter out files that are not relevant
* Add --no-version-filtering and --verbose switches
|
|
|
|
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.
|
|
Database: decrease db size
|
|
We never select by those columns, so don't set them. Reduce from 8.4 to
7.9 MB.
Upgrade the minor version of the database layout. (that database can
still be read by PROJ 8.0)
|
|
|
|
Just fixes 4 wrong transformations of v10.017
|
|
create less synthetic 'Geographic3D to GravityRelatedHeight' synthetic transformations
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
check it in the code
This is aimed at detecting running a PROJ version against a proj.db that is not
meant to work with it. This happens sometimes in complex setups mixing PROJ
versions. Hopefully this will help spotting the issue earlier.
|
|
|
|
Content mostly unchanged since v9.9
This update is "minimal" in that it mostly reflects the removal of the 'area'
table, replaced now by 'extent', 'scope' and 'usage'
Other new aspects of EPSG v10 are left aside.
|
|
|
|
Co-authored-by: jmckenna <jmckenna@gatewaygeomatics.com>
Co-authored-by: Javier Jimenez Shaw <j1@jimenezshaw.com>
Co-authored-by: Even Rouault <even.rouault@spatialys.com>
|
|
|
|
|
|
|
|
|
|
Fixes #1867
|
|
|
|
Note: a hack has been added into customizations.sql to cancel deprecatation
of USA geoid2012 grids by geoid2018 grids, as the later are not yet available
in proj-datumgrid-northamerica (https://github.com/OSGeo/proj-datumgrid/issues/55)
|
|
With limitation of https://github.com/OSGeo/PROJ/issues/1632 regarding
concatenated operations with more than 3 steps.
|
|
|
|
|
|
|
|
|
|
Minor update w.r.t 9.5.5 that adds a few new coordinate operations.
|
|
|
|
the data/epsg and data/IGNF files
|
|
This work mostly consists of:
- a C++ implementation of the ISO-19111:2018 / OGC Topic 2
"Referencing by coordinates" classes to represent Datums,
Coordinate systems, CRSs (Coordinate Reference Systems) and
Coordinate Operations.
- methods to convert between this C++ modeling and WKT1, WKT2
and PROJ string representations of those objects
- management and query of a SQLite3 database of CRS and Coordinate Operation definition
- a C API binding part of those capabilities
This is all-in-one squashed commit of the work of
https://github.com/OSGeo/proj.4/pull/1040
|
