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