| Age | Commit message (Collapse) | Author |
|
That is the option to make SQLite reject misuses of double quotes instead
of single quotes. Most SQLite builds are forgiving, but some forks proposing
a CMake build system default to SQLITE_DQS=0
|
|
to other_transformation table
|
|
ellipsoidal height
|
|
handle dynamic vertical datums, and instanciate them properly from database
|
|
|
|
dynamic datums, but not yet used
|
|
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.
|
|
This is in preparation for EPSG 9.8.11 import that supersedes a number of
grid transformation for US transformations, but the superseded and replacement
transformations don't operate on the same (source_crs, target_crs), which is
a bit weird. So in that situation, ignores the supersession.
|
|
|
|
|
|
|
|
Fixes #1913
AuthorityFactory::createBetweenGeodeticCRSWithDatumBasedIntermediates() issued
a complex SQL query that pushes the SQLite3 query plan optimizer to its limits.
Was working reasonably with sqlite 3.11, but not with later versions.
So put less constraints in the main query and do post-processing checks and
auxiliary requests to avoid such issues.
For some unknown reason, this slightly slows down a bit execution time of the
whole test_cpp_api binary (~ 10%), but couldn't come with something better,
despite trying many variations of the main SQL query. It seems that in the
general case the non-filter LEFT JOIN on the supersession table helped,
except on this EPSG:7842 case.
|
|
(gr3df97a.txt) and map them to new +proj=xyzgridshift
|
|
in the EPSG/grid_transformation table
|
|
|
|
grid_alternatives, fix related entries and simplify/robustify logic to deal with EPSG 'Geographic3D to GravityRelatedHeight' methods
|
|
Fixes #1867
|
|
CONSTRAINT CHECK
|
|
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
|
|
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.
|
|
a proj_create_vertical_crs_ex()
|
|
arbitrary number of steps (fixes #1632)
EPSG:9103 (NAD27 to ITRF2014 (1)) is now handled.
Note:EPSG:9104 (NAD27 to ITRF2014 (2)) is not currently, since it uses
for step EPSG:8861 (NAD83(HARN) to NAD83(FBN) (1))
an unsupported transformation method (NADCON5 (3D), EPSG:1075).
|
|
Currently very few transformations from/to WGS84 (Gxxxx) are registered
in the EPSG database, and there isn't even transformations between WGS84 EPSG:4326
and those ones. Consequently transformations to those realizations often
ended up as no-operation, whereas going through WGS84 EPSG:4326 will bring
more meaningful results. So register those EPSG:4326<-->WGS 84 (Gxxx)
null transformations, and when having WGS 84 (Gxxx) as source/target,
consider EPSG:4326 as an intermediate.
This change has no effect on the existing direct transformations
from/to WGS 84 (Gxxx).
|
|
|
|
- Transform conversion as a view, and when inserting into it, actually
insert into 3 tables: conversion_table, conversion_method and conversion_param,
so that method and parameter names are not repeated each time.
- Similarly for helmert_tranformation, insert into helmert_transformation_tabl
and coordinate_operation_method.
This reduces the db size from 6 344 704 bytes to 5 853 184 bytes, without
significant slowdown for queries.
|
|
|
|
|
|
to restrict and prioritize searches
|
|
transformations
|
|
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
|