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
