[gdal-dev] New OGC standard about WKT for projections

Tue May 12 02:54:28 PDT 2015

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.dixon at 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.rouault at spatialys.com <mailto:even.rouault at spatialys.com>> wrote:
> Selon Andre Vautour <andre.vautour at caris.com <mailto:andre.vautour at 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 at lists.osgeo.org <mailto:gdal-dev at 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 at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20150512/9bfa0c3c/attachment.html>