*>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.roua...@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.roua...@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....@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 <yche...@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.roua...@mines-paris.org> wrote: > > > > >> > Selon Yann Chemin <yche...@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.roua...@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@lists.osgeo.org > > > > >> >> > http://lists.osgeo.org/mailman/listinfo/gdal-dev > > > > >> >> > > > > >> >> -- > > > > >> >> ---- > > > > >> > > > > >> -- > > > > >> ---- > > > > >> _______________________________________________ > > > > >> gdal-dev mailing list > > > > >> gdal-dev@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 >
_______________________________________________ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
