[gdal-dev] Update of EPSG database to v8.4

Even Rouault even.rouault at spatialys.com
Fri Dec 5 07:03:54 PST 2014 

Le vendredi 05 décembre 2014 15:43:48, Hare, Trent a écrit :
> Even,
>    I agree we can probably purge the duplication. This was introduced
> because I couldn't find a method to designate "ographic" latitudes versus
> "ocentric" latitude systems within the WKT standard (still not clear on
> that). Thus *even values* (e.g. 49900 Mars) are ocentric and *odd
> values* (49901
> Mars) are ographic... Argh - the original "proposal
> <http://www.lpi.usra.edu/meetings/lpsc2006/pdf/1931.pdf>" is almost 10
> years old but *any feedback* is still welcome.
> 
>    There are a few bodies that need updates in that list. In short, when a
> body is defined as tri-axial, the IAU determines a best fit single
> spherical value (unfortunately this is not just the average of the three
> but can be different for each. Thus I have to manually pull the radius
> value from a published paper
> <http://astrogeology.usgs.gov/groups/IAU-WGCCRE>). I have been meaning to
> do that for sometime but since they are generally minor bodies, which we
> don't have much data for, there wasn't much pressure in getting it done.
> 
> *Let me take a stab at "version 2" over the weekend*. These were based on
> the IAU 2000 NAIF codes and IAU 2000 published report. I will tweak, where
> needed, the "IAU2000" codes since those codes are being used in some
> WMS/WCS servers, spatial ref, QGIS, etc. there are some which so now be
> tagged IAU2009 (or 2012, e.g. Mercury was recently updated). Not sure using
> that method, updated namespace based on the year, was the best idea either.
> 
> Just in case, the very simple script to convert Naif to WKT codes still
> lives here: ftp://pdsimage2.wr.usgs.gov/pub/pigpen/ogc/ (but as stated
> above, this original code doesn't fully address the tri-axial issue yet).
> 
> thanks for continuing to help with this!

Trent,

is my understanding correct that IAU2000.wkt is the result of a 20 KB Python 
script (create_IAU2000_wkt.py) run on a 3.8KB text file (naifcodes_radii_m.txt) 
?

So I can see 2 other alternatives instead of directly including IAU2000.wkt :
- either include the 2 above files in GDAL SVN, and run the python script in a 
make step of GDAL to generate  IAU2000.wkt
- include naifcodes_radii_m.txt in GDAL SVN, and "port" the python script to a 
method in the OGRSpatialReference class. The logic would have to be reversed 
(division and modulo by 100): from an EPSG-like code, find the body code and 
projection method. This would likely be more efficient too instead of ingesting 
the IAU2000.wkt file.

Even

> 
> Regards,
> Trent
> 
> 
> On Fri, Dec 5, 2014 at 1:46 AM, Even Rouault <even.rouault at spatialys.com>
> 
> wrote:
> > Le vendredi 05 décembre 2014 06:37:34, Yann Chemin a écrit :
> > > Hi all,
> > > 
> > > just want to pick up the status of this, anything new/started somewhere
> > > I could help with?
> > 
> > Not that I'm aware of.
> > 
> > Looking more closely at
> > http://svn.osgeo.org/metacrs/sr.org/srsbrowser/data/IAU2000.wkt, I see
> > that
> > each SRS is duplicated. For example 19900 and 19901 have the same WKT,
> > 19910
> > and 19911 also, and so on until the end of file. Does anyone know the
> > reason
> > for that ?
> > And the header of the file says "This file derived from the naif ID
> > Codes.txt
> > file distributed by  USGS for NASA/IAU/NAIF (http://naif.jpl.nasa.gov/)",
> > so is
> > IAU2000.wkt still up-to-date and what is the process/script to regenerate
> > it ?
> > 
> > > Trent, anything happened on your side about planetary proj support?
> > > 
> > > I am going to have a nother look about it, once answers/comments reach.
> > > Cheers,
> > > Yann
> > > 
> > > On 16 May 2014 at 04:46, Etienne Tourigny <etourigny.dev at gmail.com>
> > 
> > wrote:
> > > > You might be able to gzip compress the file
> > > > GDAL can read gzip files transparently, but I am not sure that the
> > > > csv
> > > > 
> > > >  reading code in GDAL works with compressed files.
> > > > 
> > > > On Thu, May 15, 2014 at 9:00 AM, Yann Chemin <ychemin at gmail.com>
> > 
> > wrote:
> > > >> Hi Even,
> > > >> 
> > > >> I would be interested to include it. But I see that the 1Mb
> > > >> uncompressed text is an issue.
> > > >> 
> > > >> If it was OK for the additional Mb in the source code,
> > > >> what would be the place to look into gdal code to create the patch
> > > >> needed?
> > > >> 
> > > >> Thanks,
> > > >> Yann
> > > >> 
> > > >> PS: did not copy other lists as I am not a member, registered to
> > > >> proj ML today though.
> > > >> 
> > > >> On 15/05/2014, Even Rouault <even.rouault at mines-paris.org> wrote:
> > > >> > Selon Yann Chemin <ychemin at gmail.com>:
> > > >> >> Hi,
> > > >> >> 
> > > >> >> is there planetary datum support in this new version (i.e. Moon
> > 
> > 2000,
> > 
> > > >> or
> > > >> 
> > > >> >> etc.)?
> > > >> > 
> > > >> > No, I don't think that the EPSG folks are interested in other
> > 
> > planets
> > 
> > > >> yet
> > > >> 
> > > >> > ;-)
> > > >> > But Frank mentionned some time ago (
> > 
> > http://osgeo-org.1560.x6.nabble.com/IAU-2000-Coordinate-System-Dictionar
> > 
> > > >> y-td3750798.html
> > > >> 
> > > >> > ) that he wanted to investigate how to deliver the IAU set of
> > > >> > planetary coordinate systems , but this hasn't been pursued
> > > >> > further AFAIK.
> > > >> > 
> > > >> > I see there's a version of this file here :
> > > >> > http://svn.osgeo.org/metacrs/sr.org/srsbrowser/data/IAU2000.wkt
> > > >> > 
> > > >> > Even
> > > >> > 
> > > >> >> Yann
> > > >> >> 
> > > >> >> On 14/05/2014, Even Rouault <even.rouault at mines-paris.org> wrote:
> > > >> >> > Hi,
> > > >> >> > 
> > > >> >> > I've followed the update process of the EPSG SRS database to
> > 
> > latest
> > 
> > > >> >> > v8.4,
> > > >> >> > and
> > > >> >> > just committed the updated files into libgeotiff, GDAL and PROJ
> > > >> 
> > > >> trunk.
> > > >> 
> > > >> >> > Also
> > > >> >> > 
> > > >> >> > submitted to PostGIS.
> > > >> >> > 
> > > >> >> > From what I can see, among many changes and additions, 2 new
> > > >> 
> > > >> projection
> > > >> 
> > > >> >> > methods have been added:
> > > >> >> > * 1051,Lambert Conic Conformal (2SP Michigan)
> > > >> >> > --> looks very close to standard "Lambert Conic Conformal
> > > >> >> > (2SP)",
> > > >> 
> > > >> with
> > > >> 
> > > >> >> > the
> > > >> >> > addition of a new parameter K, the ellipsoid scaling factor.
> > > >> >> > * 1052,Colombia Urban
> > > >> >> > 
> > > >> >> > I don't think any of those 2 new methods are currently handled
> > > >> >> > by
> > > >> 
> > > >> PROJ,
> > > >> 
> > > >> >> > so
> > > >> >> > the
> > > >> >> > new PCS based on those projection methods (3 Michigan SRS, and
> > > >> 
> > > >> several
> > > >> 
> > > >> >> > dozains
> > > >> >> > of Colombia PCS) will not be handled by GDAL nor PROJ.
> > > >> >> > 
> > > >> >> > Regarding GDAL, I've improved the add_esri_column.py script
> > > >> >> > (see http://trac.osgeo.org/geotiff/changeset/2446), so that we
> > > >> >> > have
> > 
> > more
> > 
> > > >> >> > ESRI
> > > >> >> > DATUM
> > > >> >> > names. That should make morphing from/to ESRI .prj files a bit
> > > >> 
> > > >> better.
> > > >> 
> > > >> >> > Regarding PROJ.4 'espg' and PostGIS spatial_ref_sys.sql files,
> > 
> > I've
> > 
> > > >> >> > also
> > > >> >> > added
> > > >> >> > the list of SRS that are GEOCCS (GeoCentric) and COMPD_CS
> > 
> > (Compound
> > 
> > > >> >> > Horizontal
> > > >> >> > + Vertical).
> > > >> >> > 
> > > >> >> > Please let me know if you see issues.
> > > >> >> > 
> > > >> >> > libgeotiff:
> > > >> >> > http://trac.osgeo.org/geotiff/ticket/63
> > > >> >> > http://trac.osgeo.org/geotiff/changeset/2447
> > > >> >> > 
> > > >> >> > GDAL:
> > > >> >> > http://trac.osgeo.org/gdal/ticket/5462
> > > >> >> > http://trac.osgeo.org/gdal/changeset/27322
> > > >> >> > 
> > > >> >> > PROJ:
> > > >> >> > http://trac.osgeo.org/proj/ticket/236
> > > >> >> > http://trac.osgeo.org/proj/changeset/2448
> > > >> >> > 
> > > >> >> > Submitted for PostGIS :
> > > >> >> > http://trac.osgeo.org/postgis/ticket/2737
> > > >> >> > 
> > > >> >> > Best regards,
> > > >> >> > 
> > > >> >> > Even
> > > >> >> > 
> > > >> >> > --
> > > >> >> > Geospatial professional services
> > > >> >> > http://even.rouault.free.fr/services.html
> > > >> >> > _______________________________________________
> > > >> >> > gdal-dev mailing list
> > > >> >> > gdal-dev at lists.osgeo.org
> > > >> >> > http://lists.osgeo.org/mailman/listinfo/gdal-dev
> > > >> >> 
> > > >> >> --
> > > >> >> ----
> > > >> 
> > > >> --
> > > >> ----
> > > >> _______________________________________________
> > > >> gdal-dev mailing list
> > > >> gdal-dev at lists.osgeo.org
> > > >> http://lists.osgeo.org/mailman/listinfo/gdal-dev
> > 
> > --
> > Spatialys - Geospatial professional services
> > http://www.spatialys.com

-- 
Spatialys - Geospatial professional services
http://www.spatialys.com

More information about the gdal-dev mailing list