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