[gdal-dev] Adding missing EPSG codes to PROJ.4 and GDAL

Even Rouault even.rouault at spatialys.com
Sat Sep 2 11:31:08 PDT 2017


Hi,

> 
> I have recently compared the downloadable SQL files of the EPSG database
> (v9.1) with the output of gdalsrsinfo (v2.2.1). There are currently 368
> CRS_codes missing, and I would like to have them reduced.
> 
> You can find a csv list at
> https://github.com/Andre-J/EPSG/blob/master/missing_epsg.csv
> 
> Some CRS might fail due to exotic projection definitions, but there are
> also several transverse mercator based projections, which should be
> integrateable into PROJ.4 and GDAL.
> 
> Has there anybody worked lately on integrating them, and what would be
> the safest way to do that without them getting kicked out with the next
> EPSG database update?.

The procedure to integrate a new EPSG database in libgeotiff ==> GDAL ==> proj.4 + PostGIS 
is described at:
https://trac.osgeo.org/geotiff/browser/trunk/libgeotiff/csv/README

If not done by anyone else, I generally run it a couple of months before each GDAL major 
release to avoid doing it too often.

> And where should doubts be discussed: on the
> Proj.4 mailing list, the gdal-dev mailing list or as Github issues?

Depends on the issue... Technically if it is an issue in the initial python import script, should be 
in geotiff Trac. If it is an issue in the GDAL epsg_tr.py script / importFromEPSG() / missing 
mapping from a method, then in GDAL. If it is missing support for a projection in proj.4, in 
proj github issues.

> 
> There are a number of Colombian MAGNA-SIRGAS local grids, based on a
> projection plane *above* the ellipsoid (unfortunately different for
> every grid). This is similiar to the (now deprecated) NAD27 Michigan
> based CRS EPSG:26811, 26812 and 26813. The solution there was to create
> a new ellipsoid (EPSG:4268) with a and b increased by the projection
> plane heigt above ellipsoid. This could be applied to the MAGNA SIRGAS
> local grids as well, but would possibly need the creation of Geografic
> CRS (without a EPSG code) for each case.

It isn't obvious to me that the trick you describe above can be reused for those grids, but 
they will indeed require code additions in proj.4 and GDAL. Looking at
https://www.epsg-registry.org/export.htm?wkt=urn:ogc:def:crs:EPSG::6244
and
https://www.epsg-registry.org/export.htm?wkt=urn:ogc:def:crs:EPSG::6245
use a "Colombia Urban" projection method that isn't AFAIK currently handled by proj.4 and 
GDAL.

This Columbian Urban projection is described in paragraph 1.3.19 of
http://www.epsg.org/Portals/0/373-07-2.pdf , so could be served as the base to add support 
for it in proj.4

> 
> The list also contains a number of "NAD83(HARN) / WISCRS" for Wisconsin
> counties. I wonder why those got dropped, while the "NAD83(2011) /
> WISCRS" codes for the same counties are included.

They didn't get dropped. As far as I can see they are new in EPSG v9.1. "http://www.epsg.org/
EPSGDataset/WhatIsNew.aspx" : "New data for ... United States (AZ and WI)"

Even

-- 
Spatialys - Geospatial professional services
http://www.spatialys.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20170902/f9278b61/attachment.html>


More information about the gdal-dev mailing list