<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<br>
<div class="moz-cite-prefix">On 2015-04-13 11:01, Pepijn Van
Eeckhoudt wrote:<br>
</div>
<blockquote
cite="mid:06A435AC-3C1D-4AE8-8F91-12D11319817B@vaneeckhoudt.net"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
<br class="">
<div>
<blockquote type="cite" class="">
<div text="#000000" bgcolor="#FFFFFF" class="">I am not sure I
follow what this has to do with the projection name in WKT.
The newer WKT specification (ISO 19162) relies solely on the
identifier to determine which operation method to use to
project coordinates, but the older WKT tends to follow OGC
01-009 which lists explicit names to use for the
projections. So regardless of what the EPSG registry uses
for a name, this is the name that is supposed to be used for
the OGC WKT as far as I am concerned:<br class="">
OGC 01-009 (<a moz-do-not-send="true"
class="moz-txt-link-freetext"
href="http://www.opengeospatial.org/standards/ct">http://www.opengeospatial.org/standards/ct</a>):
"Mercator_1SP"<br class="">
<br class="">
Does someone know of another WKT spec that uses that
"Mercator variant A" name, or I am missing something?<br
class="">
</div>
</blockquote>
</div>
<div class=""><br class="">
</div>
When we were defining the GeoPackage spec I had hoped to be able
to point people to one definitive list of projection names and
parameters so we could say ‘use this, end of story’. I remember
discussing this with the CRS WKT people at one of the OGC TCs.
IIRC they told me there never was a specification that
standardised the projection names. The best practice is to use
names that are used in some registry, the EPSG one being the most
commonly used one.
<div class=""><br class="">
</div>
<div class="">The coordinate transformation service spec isn’t
actually relevant for GeoPackage and is certainly not some
normative reference for WKT projection names. I was under the
same impression until I again discussed this with the relevant
OGC members and was told that it is not.</div>
<div class="">The spec that is relevant for GeoPackage is the
simple features common architecture one (OGC 06-103r4), section
9. That spec lists a number of projection names in annex B, but
that annex is informative and non-exhaustive.</div>
<div class=""><br class="">
</div>
<div class="">So in short there’s, unfortunately, no such thing as
‘standardised’ WKT wrt the projection and parameter names.</div>
</blockquote>
Thanks Pepijn for these clarifications. I was aware of the simple
feature specs as well, but did not find that annex when I was
drafting my original reply.<br>
<br>
It might be helpful for the OGC to put out a policy guideline like
they did for the axis ordering <a class="moz-txt-link-freetext" href="http://www.ogcnetwork.net/axisorder">http://www.ogcnetwork.net/axisorder</a>.
I've looked at several of the WKT specs over the years and would not
have reached that conclusion.
<blockquote
cite="mid:06A435AC-3C1D-4AE8-8F91-12D11319817B@vaneeckhoudt.net"
type="cite">
<div class=""><br class="">
</div>
<div class="">
<blockquote type="cite" class=""><span style="background-color:
rgb(255, 255, 255);" class="">I'm not opposed to mapping
that "Mercator variant A" name to SRS_PT_MERCATOR_1SP on WKT
import, but I think there's a limit to how far one should go
to support non-standard WKT. I am not sure what modern EPSG
names have to do with the explicitly named WKT projection
strings that are defined in the actual specification, even </span><a
moz-do-not-send="true" href="http://spatialreference.org"
style="background-color: rgb(255, 255, 255);" class="">spatialreference.org</a><span
style="background-color: rgb(255, 255, 255);" class=""> is
still using "Mercator_1SP" for the OGC WKT.</span></blockquote>
<br class="">
</div>
<div class="">IIRC <a moz-do-not-send="true"
href="http://spatialreference.org" class="">spatialreference.org</a>
isn’t being actively maintained anymore. If <a
moz-do-not-send="true"
href="http://trac.osgeo.org/metacrs/browser/sr.org" class="">http://trac.osgeo.org/metacrs/browser/sr.org</a> is
still the source repo, last relevant update is from 5 years ago.</div>
<div class="">Last time I reviewed the source code, the WKT it
displays is produced by proj.4 and the data for it is sourced
from proj.4’s extract of the EPSG database so of course that’s
going to roundtrip well. :)</div>
<div class=""><br class="">
</div>
<div class="">Since all this data is being source from the EPSG
database anyway it seems best to use that as authoritative
source. The main name for <a moz-do-not-send="true"
href="http://www.epsg-registry.org/report.htm?type=selection&entity=urn:ogc:def:method:EPSG::9804&reportDetail=long&style=urn:uuid:report-style:default-with-code&style_name=OGP%20Default%20With%20Code&title="
class="">EPSG:9804</a> is 'Mercator (variant A)' now. The
'Mercator (1SP)’ name is still present in the database as an
alias. The name change dates back to 2010 stating:</div>
<div class=""><br class="">
</div>
<div class="">
<blockquote type="cite" class="">
<div class="componentProperty" style="padding-bottom: 5px;
font-family: sans-serif;"><span dojoattachpoint="titleNode"
class="emphasized_label propertyTitle" style="font-size:
0.8em; font-weight: bold;">Code: </span>
<div dojoattachpoint="propertyNode"
dojoattachevent="onclick: displayEntity" class="show
emphasized_content propertyValue" style="display: inline;
font-size: 0.8em; font-style: italic; font-weight: bold;
color: rgb(51, 51, 255);">EPSG::2010.058 </div>
</div>
<div class="componentProperty" style="padding-bottom: 5px;
font-family: sans-serif;"><span dojoattachpoint="titleNode"
class="emphasized_label propertyTitle" style="font-size:
0.8em; font-weight: bold;">Reporter: </span>
<div dojoattachpoint="propertyNode"
dojoattachevent="onclick: displayEntity" class="show
emphasized_content propertyValue" style="display: inline;
font-size: 0.8em; font-style: italic; font-weight: bold;
color: rgb(51, 51, 255);">Jay Hollingsworth; Schlumberger </div>
</div>
<div class="componentProperty" style="padding-bottom: 5px;
font-family: sans-serif;"><span dojoattachpoint="titleNode"
class="emphasized_label propertyTitle" style="font-size:
0.8em; font-weight: bold;">Request: </span>
<div dojoattachpoint="propertyNode"
dojoattachevent="onclick: displayEntity" class="show
emphasized_content propertyValue" style="display: inline;
font-size: 0.8em; font-style: italic; font-weight: bold;
color: rgb(51, 51, 255);">Review Mercator and Oblique
Mercator method names </div>
</div>
<div class="componentProperty" style="padding-bottom: 5px;
font-family: sans-serif;"><span dojoattachpoint="titleNode"
class="emphasized_label propertyTitle" style="font-size:
0.8em; font-weight: bold;">Actions Taken: </span>
<div dojoattachpoint="propertyNode"
dojoattachevent="onclick: displayEntity" class="show
emphasized_content propertyValue" style="display: inline;
font-size: 0.8em; font-style: italic; font-weight: bold;
color: rgb(51, 51, 255);">For methods 9804-05, 9812-13 and
9815, amended name and added alias. For method 9815 also
corrected forward formula for az=90deg case. Added method
1044. For projections 12150, 15001, 15031, 19871-72,
19894-95 and 19956-58, in remarks updated method names.
For CRS 3375, in remarks inserted missing and removed
spurious space.</div>
</div>
</blockquote>
</div>
</blockquote>
<br>
Thanks again, that answers the main question of my last reply. If
that is the case, I'll make sure to fallback to a name-lookup of the
EPSG registry operation method in our in-house implementation. We do
use GDAL for the WKT parsing, but we then still have to create an
operation method in our model from the projection's name.<br>
<br>
<blockquote
cite="mid:06A435AC-3C1D-4AE8-8F91-12D11319817B@vaneeckhoudt.net"
type="cite">
<div class="">Best regards,</div>
<div class=""><br class="">
</div>
<div class="">Pepijn</div>
</blockquote>
<br>
André<br>
</body>
</html>