<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
The way I see it, the new spec does clear up some big holes like:<br>
<ol>
<li> 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)</li>
<li>Knowing the units of projection parameters (9.3.4)</li>
</ol>
<div class="moz-cite-prefix">On 2015-05-09 12:38, Even Rouault
wrote:<br>
</div>
<blockquote cite="mid:1431185882.554e29dad3f88@imp.free.fr"
type="cite">
<pre wrap="">Quoting Jukka Rahkonen <a class="moz-txt-link-rfc2396E" href="mailto:jukka.rahkonen@maanmittauslaitos.fi"><jukka.rahkonen@maanmittauslaitos.fi></a>:
</pre>
<blockquote type="cite">
<pre wrap="">Hi,
There seems to be a new OGC (and ISO) standard "Geographic information -
Well-known text representation of coordinate reference systems"
<a class="moz-txt-link-freetext" href="http://docs.opengeospatial.org/is/12-063r5/12-063r5.html">http://docs.opengeospatial.org/is/12-063r5/12-063r5.html</a>
</pre>
</blockquote>
<pre wrap="">
On a quick look, one thing that struck me is that there will no longer be any
direct equivalent of TOWGS84.</pre>
</blockquote>
The differences between the older WKT spec and the one currently
implemented by GDAL are explained in Annex C. For TOWGS84
specifically, see C 3.3.3.<br>
<br>
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.<br>
<br>
<blockquote type="cite">18.1 Bound CRS</blockquote>
<blockquote type="cite"> 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.</blockquote>
<blockquote cite="mid:1431185882.554e29dad3f88@imp.free.fr"
type="cite">
<pre wrap=""> 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.</pre>
</blockquote>
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. :)<br>
<br>
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.<br>
<br>
I for one certainly hope it gets adopted by the industry, as I find
there is too much ambiguity in the old WKT specification to truly
achieve interoperability,<br>
André<br>
</body>
</html>