<div dir="ltr"><i>>is my understanding correct that IAU2000.wkt is the result of a 20 KB Python<br>>script (create_IAU2000_wkt.py) run on a 3.8KB text file (naifcodes_radii_m.txt)?</i><div><br></div><div>Yes - but needs a couple minor tweaks.<br><br><i>>So I can see 2 other alternatives instead of directly including IAU2000.wkt :<br></i><div class="gmail_extra"><br></div><div class="gmail_extra">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.</div><div class="gmail_extra"><br></div><div class="gmail_extra">-Trent<br></div><div class="gmail_extra"><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Dec 5, 2014 at 8:03 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:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Le vendredi 05 décembre 2014 15:43:48, Hare, Trent a écrit :<br>
<span class="">> Even,<br>
>    I agree we can probably purge the duplication. This was introduced<br>
> because I couldn't find a method to designate "ographic" latitudes versus<br>
> "ocentric" latitude systems within the WKT standard (still not clear on<br>
</span>> that). Thus *even values* (e.g. 49900 Mars) are ocentric and *odd<br>
> values* (49901<br>
<span class="">> Mars) are ographic... Argh - the original "proposal<br>
</span>> <<a href="http://www.lpi.usra.edu/meetings/lpsc2006/pdf/1931.pdf" target="_blank">http://www.lpi.usra.edu/meetings/lpsc2006/pdf/1931.pdf</a>>" is almost 10<br>
> years old but *any feedback* is still welcome.<br>
<span class="">><br>
>    There are a few bodies that need updates in that list. In short, when a<br>
> body is defined as tri-axial, the IAU determines a best fit single<br>
> spherical value (unfortunately this is not just the average of the three<br>
> but can be different for each. Thus I have to manually pull the radius<br>
> value from a published paper<br>
</span>> <<a href="http://astrogeology.usgs.gov/groups/IAU-WGCCRE" target="_blank">http://astrogeology.usgs.gov/groups/IAU-WGCCRE</a>>). I have been meaning to<br>
<span class="">> do that for sometime but since they are generally minor bodies, which we<br>
> don't have much data for, there wasn't much pressure in getting it done.<br>
><br>
</span>> *Let me take a stab at "version 2" over the weekend*. These were based on<br>
<span class="">> the IAU 2000 NAIF codes and IAU 2000 published report. I will tweak, where<br>
> needed, the "IAU2000" codes since those codes are being used in some<br>
> WMS/WCS servers, spatial ref, QGIS, etc. there are some which so now be<br>
> tagged IAU2009 (or 2012, e.g. Mercury was recently updated). Not sure using<br>
> that method, updated namespace based on the year, was the best idea either.<br>
><br>
> Just in case, the very simple script to convert Naif to WKT codes still<br>
> lives here: <a href="ftp://pdsimage2.wr.usgs.gov/pub/pigpen/ogc/" target="_blank">ftp://pdsimage2.wr.usgs.gov/pub/pigpen/ogc/</a> (but as stated<br>
> above, this original code doesn't fully address the tri-axial issue yet).<br>
><br>
> thanks for continuing to help with this!<br>
<br>
</span>Trent,<br>
<br>
is my understanding correct that IAU2000.wkt is the result of a 20 KB Python<br>
script (create_IAU2000_wkt.py) run on a 3.8KB text file (naifcodes_radii_m.txt)<br>
?<br>
<br>
So I can see 2 other alternatives instead of directly including IAU2000.wkt :<br>
- either include the 2 above files in GDAL SVN, and run the python script in a<br>
make step of GDAL to generate  IAU2000.wkt<br>
- include naifcodes_radii_m.txt in GDAL SVN, and "port" the python script to a<br>
method in the OGRSpatialReference class. The logic would have to be reversed<br>
(division and modulo by 100): from an EPSG-like code, find the body code and<br>
projection method. This would likely be more efficient too instead of ingesting<br>
the IAU2000.wkt file.<br>
<span class=""><font color="#888888"><br>
Even<br>
</font></span><div class=""><div class="h5"><br>
><br>
> Regards,<br>
> Trent<br>
><br>
><br>
> On Fri, Dec 5, 2014 at 1:46 AM, Even Rouault <<a href="mailto:even.rouault@spatialys.com">even.rouault@spatialys.com</a>><br>
><br>
> wrote:<br>
> > Le vendredi 05 décembre 2014 06:37:34, Yann Chemin a écrit :<br>
> > > Hi all,<br>
> > ><br>
> > > just want to pick up the status of this, anything new/started somewhere<br>
> > > I could help with?<br>
> ><br>
> > 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<br>
> > that<br>
> > each SRS is duplicated. For example 19900 and 19901 have the same WKT,<br>
> > 19910<br>
> > and 19911 also, and so on until the end of file. Does anyone know the<br>
> > reason<br>
> > for that ?<br>
> > And the header of the file says "This file derived from the naif ID<br>
> > 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>)",<br>
> > so is<br>
> > IAU2000.wkt still up-to-date and what is the process/script to regenerate<br>
> > it ?<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>><br>
> ><br>
> > 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<br>
> > > > 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>><br>
> ><br>
> > 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<br>
> > > >> proj 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<br>
> ><br>
> > 2000,<br>
> ><br>
> > > >> or<br>
> > > >><br>
> > > >> >> etc.)?<br>
> > > >> ><br>
> > > >> > No, I don't think that the EPSG folks are interested in other<br>
> ><br>
> > 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>
> ><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<br>
> > > >> > further 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<br>
> ><br>
> > latest<br>
> ><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<br>
> > > >> >> > (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<br>
> > > >> >> > 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<br>
> > > >> >> > (see <a href="http://trac.osgeo.org/geotiff/changeset/2446" target="_blank">http://trac.osgeo.org/geotiff/changeset/2446</a>), so that we<br>
> > > >> >> > have<br>
> ><br>
> > more<br>
> ><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,<br>
> ><br>
> > I've<br>
> ><br>
> > > >> >> > also<br>
> > > >> >> > added<br>
> > > >> >> > the list of SRS that are GEOCCS (GeoCentric) and COMPD_CS<br>
> ><br>
> > (Compound<br>
> ><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>
> > Spatialys - Geospatial professional services<br>
> > <a href="http://www.spatialys.com" target="_blank">http://www.spatialys.com</a><br>
<br>
--<br>
Spatialys - Geospatial professional services<br>
<a href="http://www.spatialys.com" target="_blank">http://www.spatialys.com</a><br>
</div></div></blockquote></div><br></div></div></div>