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

[Damian Dixon]

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

I don't know how complete this is.



On 11 May 2015 at 23:10, Even Rouault <even.rouault at spatialys.com> wrote:

> Selon Andre Vautour <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
> _______________________________________________
> 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/584d79e8/attachment-0001.html>