And OGC finally got round to making the spec public. See http://www.opengeospatial.org/pressroom/pressreleases/2217 <http://www.opengeospatial.org/pressroom/pressreleases/2217> and http://docs.opengeospatial.org/is/12-063r5/12-063r5.html <http://docs.opengeospatial.org/is/12-063r5/12-063r5.html>
Pepijn > On 12 May 2015, at 11:17, Damian Dixon <damian.di...@gmail.com> wrote: > > ESRI have open sourced an implementation of a draft of the standard. > > The code can be found here: > > https://github.com/Esri/ogc-crs-wkt-parser > <https://github.com/Esri/ogc-crs-wkt-parser> > > I don't know how complete this is. > > > > On 11 May 2015 at 23:10, Even Rouault <even.roua...@spatialys.com > <mailto:even.roua...@spatialys.com>> wrote: > Selon Andre Vautour <andre.vaut...@caris.com > <mailto:andre.vaut...@caris.com>>: > > > The way I see it, the new spec does clear up some big holes like: > > > > 1. Being able to specify an unambiguous operation/projection method (by > > identifier) for projections instead of loosely relying on the > > projection's name (9.3.3) > > 2. Knowing the units of projection parameters (9.3.4) > > Yes, there are of course interesting improvements. I'm often playing the > devil's > adovcate. > > > > > The transformation is not part of the coordinate reference system in > > both the EPSG registry and the ISO 19111 specification. What was weird > > with the older WKT spec is that you could have an identified CRS that > > had TOWGS84 specified, even though that definition is technically not > > part of the identified object. That being said, for a lot of practical > > applications, the transformation is essential, so it'll be interesting > > to see how it all plays out. > > > > > 18.1 Bound CRS > > > The definition of a CRS is not dependent upon any relationship to an > > > independent CRS. However in an implementation that merges datasets > > > referenced to differing CRSs, it is sometimes useful to associate the > > > definition of the transformation that has been used with the CRS > > > definition. > > > AFAIU, the BOUNDCRS concept which can embrace the > > > concept of TOWGS84 through a Coordinate Frame method is to be used when > > > the > > > transform to the TARGETCRS has already been done and document what was the > > > SOURCRS and the transformation applied. > > Even, I'm not sure if I completely understood that last part. It's > > entirely possible that what follows is what you were trying to say. If > > that is the case, fell free to just ignore me. :) > > > > The way I understand the BOUNDCRS concept is that it binds a > > transformation to a given CRS. That is, even though the transformation > > is not part of the CRS, you can use that construct to associate the > > transformation with a CRS (as it was previously done with TOWGS84). So, > > for a TOWGS84 equivalence, you'd have a BOUNDCRS where the source is the > > CRS being defined, the target would be WGS 84, and the operation method > > would be a 7 parameter geocentric transformations with the rotation > > convention (position vector/coordinate frame) explicitly defined. > > Hum, apparently I didn't understand the spec the way you explain it (I > wouldn't > bet much on the correctness of my interpretation), although I would prefer > your > interpretation to mine. My understanding was that if you have a BOUNDCRS the > CRS > that would apply would be the TARGETCRS and you would know that the data > originaly was in SOURCECRS (this comes from how I understand the sentence "it > is > sometimes useful to associate the definition of the transformation that has > been > used with the CRS definition."). But you seem to understand it the other way, > i.e the SOURCECRS would still apply ? > > Anyway it doesn't seem likely that most data would come with a BOUNDCRS > expliciting the tranform to be used to go to WGS 84, so that would mean that > GDAL for example would have to query it from its own EPSG database. Actually, > that something we should ideally already do for example with the ESRI WKT of > .prj files, since they do not have TOWG84 nodes. > > Even > > > -- > Spatialys - Geospatial professional services > http://www.spatialys.com <http://www.spatialys.com/> > _______________________________________________ > gdal-dev mailing list > gdal-dev@lists.osgeo.org <mailto:gdal-dev@lists.osgeo.org> > http://lists.osgeo.org/mailman/listinfo/gdal-dev > <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
_______________________________________________ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
