PROJ - Forked from https://github.com/OSGeo/PROJ

Age	Commit message (Collapse)	Author
2020-01-07	Database: insert PROJ.4 +datum values in alias_name table under PROJ authority	Even Rouault

2019-12-25	Database: tune accuracy of Canadian NTv1 file w.r.t NTv2	Even Rouault
	As on import of EPSG, we remove the supersession of Canadian NTv1 file w.r.t NTv2 (because the default behaviour of PROJ is to ignore superseded operations). However the NTv1 operation is advertized with an accuracy of 1m, whereas NTv2 is advertized with 1.5m. Consequently on areas where both files are valid, and if both files are available, NTv1 would be selected. So as a workaround, worsen the NTv1 accuracy to 2m so that NTv2 is used in priority.
2019-11-17	createOperations(): remove the concept of geodetic_datum_preferred_hub	Even Rouault
	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.
2019-11-02	Database: add mapping between EPSG geoid and PROJ grid names for GEOID99, ↵	Even Rouault
	03, 06, 09 and 18. Related to https://github.com/OSGeo/proj-datumgrid/pull/60 that add those grids in proj-datumgrid-north-america
2019-11-02	Add a geoid_model name in database, use GEOIDMODEL for transformations, add ↵	Even Rouault
	a proj_create_vertical_crs_ex()
2019-10-15	Database: update to EPSG v9.8.3	Even Rouault
	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)
2019-09-12	Coordinate transformation: improve transformations from/to WGS84 (Gxxxx)	Even Rouault
	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).
2019-06-06	createFromUserInput(): support OGC URN to create projectedCRS, for example ↵	Even Rouault
	to instanciate a projected 3D CRS
2019-05-18	customizations.sql: remove the removal of the deprecation entry of RAF09 by ↵	Even Rouault
	RAF18
2019-05-06	createOperations(): for 'Amersfoort / RD New + NAP height' (EPSG:7415) to ↵	Even Rouault
	ETRS89 (EPSG:4937), make sure that the vgridshift is applied first (ie on Amersfoort datum) before the hgridshift
2019-03-25	Database: add operation_version column to coordinate operation tables	Even Rouault

2019-03-22	Port custom ellipsoid definitions from QGIS (#1337)	Nyall Dawson

2019-02-22	proj.db: tune so that 'NGF IGN69 height to RGF93' uses the RAF09.gtx grid	Even Rouault

2018-12-06	Coordinate operation search: add a authority_to_authority_preference table ↵	Even Rouault
	to restrict and prioritize searches
2018-11-14	Implement RFC 2: Initial integration of "GDAL SRS barn" work	Even Rouault
	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