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