Matt, interesting discussions going on indeed. My perspective, having to model CRS request parameters for transformation etc and to establish a CRS URL resolver, is to understand a sufficiently general slate of concepts. Some of the issues of representation do not directly apply for my task (my - possibly wrong - understanding is that it also addresses redundant short-hand information), however this still is interesting for me in the sense that I can get the gist of CRS handling in the communities' practice.
-Peter ________________________________________ From: wcs.swg-bounces+p.baumann=jacobs-university...@lists.opengeospatial.org [wcs.swg-bounces+p.baumann=jacobs-university...@lists.opengeospatial.org] on behalf of Matthew Austin [[email protected]] Sent: Thursday, September 08, 2011 3:20 PM To: [email protected]; [email protected]; [email protected] Subject: Re: [WCS.swg] [gdal-dev] NetCDF and datum handling suggestion Peter, There has been much discussion about projections in the CF-Community recently. I'm following up with Etienne's recommendation to engage the CF-Community in this discussion of how to handle projection information in CF. Matt On 9/8/2011 2:17 AM, Peter Baumann wrote: > Hi WCSers, > > this is to inform you about some interesting discussion going on in > the GDAL community. It directly relates to our current work on > redesigning OGC's CRS handling for coverages (and beyond). > > cheers, > Peter > > > On 09/07/2011 10:49 PM, Etienne Tourigny wrote: >> Thanks for the info Even >> >> I can see that there is not yet "One standard to rule them all"... >> Correct me if I am wrong: is WKT the preferred way GDAL stores the >> information? >> >> There was a proposal some time ago in the CF trac to add descriptive >> variables such as crs_id (EPSG code), crs_name and crs_wkt. >> https://cf-pcmdi.llnl.gov/trac/ticket/18 (pointed out by Patrick) >> https://cf-pcmdi.llnl.gov/trac/ticket/9 >> https://cf-pcmdi.llnl.gov/trac/ticket/27 >> >> However, these were dropped because of disagreement between the >> participants and the simpler and current approach was adopted (specify >> the numeric values of the projection and datum). >> Unfortunately, the issue has not been discussed since. >> >> >> I think our solution should address the following >> >> 1) Storing projection and datum in the netcdf file with 100% CF >> compliance. >> 2) Storing complete information so that it can be retrieved later by >> GDAL, This is already done by writing and reading the WKT. >> 3) Making sure that the CF and WKT are not contradictory, in the case >> that the projection was modified by another program, but left the WKT >> intact. >> 4) Reading CF-compliant projection information and translating that >> into WKT (this could eliminate the need for 2 and 3) >> >> Perhaps 4 can be achieved with another tool external to GDAL (as >> suggested in the CF discussions). >> >> >> Is there anyone who would be inclined to engage in a discussion within >> the CF community so that any or all of proj4, epsg and wkt be included >> as a CF standard? >> >> Regards, Etienne >> >> On Wed, Sep 7, 2011 at 4:54 PM, Even Rouault >> <[email protected]> wrote: >>>> How important is this information? Assuming we drop all the citation >>>> strings, or authority names and codes, but retain the important >>>> parameters of each projection (in CF and proj format), are we missing >>>> anything important numerically? >>>> >>>> In other words, are there any show-stopper issues that would keep us >>>> from using proj4 instead of wkt? >>> Generally not. You indeed mentionned a significant word, >>> "numerically", which >>> indicates that you are interested more in the information for >>> reprojection >>> purposes, than strict (not to say pedantic ;-)) identification of >>> the SRS. If >>> the software that process the dataset all use proj4 and the proj4 >>> string is an >>> adequate representation of the SRS, then it is a perfect fit. >>> >>> There are situations where 2 distincts SRS from the EPSG database will >>> translate into identical proj4 string. For example, just looking at >>> the very >>> beginning of the epsg file provided with proj4, I can see : >>> >>> # TWD97 >>> <3824> +proj=longlat +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 +no_defs<> >>> >>> # IGRS >>> <3889> +proj=longlat +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 +no_defs<> >>> >>> The corresponding WKT (given by using gdal utility 'testepsg >>> EPSG:XXXX') are : >>> >>> GEOGCS["TWD97", >>> DATUM["Taiwan_Datum_1997", >>> SPHEROID["GRS 1980",6378137,298.257222101, >>> AUTHORITY["EPSG","7019"]], >>> TOWGS84[0,0,0,0,0,0,0], >>> AUTHORITY["EPSG","1026"]], >>> PRIMEM["Greenwich",0, >>> AUTHORITY["EPSG","8901"]], >>> UNIT["degree",0.0174532925199433, >>> AUTHORITY["EPSG","9122"]], >>> AUTHORITY["EPSG","3824"]] >>> >>> GEOGCS["IGRS", >>> DATUM["Iraqi_Geospatial_Reference_System", >>> SPHEROID["GRS 1980",6378137,298.257222101, >>> AUTHORITY["EPSG","7019"]], >>> TOWGS84[0,0,0,0,0,0,0], >>> AUTHORITY["EPSG","1029"]], >>> PRIMEM["Greenwich",0, >>> AUTHORITY["EPSG","8901"]], >>> UNIT["degree",0.0174532925199433, >>> AUTHORITY["EPSG","9122"]], >>> AUTHORITY["EPSG","3889"]] >>> >>> Are the Taiwan_Datum_1997 and Iraqi_Geospatial_Reference_System >>> really the >>> same, or is it because we haven't captured the difference, or it is >>> too subtle >>> to be modelled with proj4, or it would require some grids that are not >>> available, etc... I have no idea. >>> >>> Also you should be aware that some SRS have no translation into >>> proj4 strings >>> due to unsupported projection methods for example. >>> >>> Using proj4 strings is not a total heresy however. Postgis is a >>> famous and >>> widespread example of the use of proj4 strings. Although in the >>> Postgis case, >>> the spatial_ref_sys table includes authority names and code columns, >>> and the >>> SRID is used as a key in the geometry_columns table. So you can fix >>> proj4 >>> strings in a centralized way if needed. >>> >>> Another point to have in mind is that the proj4 strings (at least >>> the ones >>> provided in the epsg file that comes with proj4) are generally >>> derived from the >>> EPSG database, and there can be imperfections in the way they are >>> translated, >>> or later improvements. A recent proj4 change has added for example >>> TOWGS84 >>> statements in a lot of cases where they were missing before. >>> >>> You can look at the following page which gives details on how GDAL, >>> proj4, >>> libtiff and postgis SRS databases are built from the EPSG database : >>> >>> http://svn.osgeo.org/metacrs/geotiff/trunk/libgeotiff/csv/README >>> >>> Some could also say that proj4 strings are not a very formal >>> definition, and >>> that WKT has a better potential to act as a standard. However, reading >>> http://home.gdal.org/projects/opengis/wktproblems.html might be >>> enlightning. >>> (Note : apparently the page has been written quite some time ago, >>> and some >>> statements do no longer apply, for example the one about PostGIS. >>> PostGIS has >>> used proj4 strings and not WKT for a long time. But most of the rest >>> still >>> apply however.) >>> >>> Not sure to really have helped you. There are issues with either >>> using WKT or >>> proj4 strings. >>> >>> >>>> _______________________________________________ >>>> gdal-dev mailing list >>>> [email protected] >>>> http://lists.osgeo.org/mailman/listinfo/gdal-dev >> _______________________________________________ >> gdal-dev mailing list >> [email protected] >> http://lists.osgeo.org/mailman/listinfo/gdal-dev > _______________________________________________ WCS.swg mailing list [email protected] https://lists.opengeospatial.org/mailman/listinfo/wcs.swg _______________________________________________ CF-metadata mailing list [email protected] http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
