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

Fri Dec 5 07:24:35 PST 2014

*>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)?*

Yes - but needs a couple minor tweaks.

*>So I can see 2 other alternatives instead of directly including
IAU2000.wkt :*

Both good ideas. I like to keep things as simple as possible so I will
defer to your judgment as what you think is best. I will fix the script
then we can decide if it should be included or ported.

-Trent

On Fri, Dec 5, 2014 at 8:03 AM, Even Rouault <even.rouault at spatialys.com>
wrote:

> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20141205/6c2c7023/attachment-0001.html>