On 2015-04-13 11:01, Pepijn Van Eeckhoudt wrote:
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:
OGC 01-009 (http://www.opengeospatial.org/standards/ct): "Mercator_1SP"
Does someone know of another WKT spec that uses that "Mercator
variant A" name, or I am missing something?
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.
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.
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.
So in short there’s, unfortunately, no such thing as ‘standardised’
WKT wrt the projection and parameter names.
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.
It might be helpful for the OGC to put out a policy guideline like they
did for the axis ordering http://www.ogcnetwork.net/axisorder. I've
looked at several of the WKT specs over the years and would not have
reached that conclusion.
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
spatialreference.org <http://spatialreference.org> is still using
"Mercator_1SP" for the OGC WKT.
IIRC spatialreference.org <http://spatialreference.org> isn’t being
actively maintained anymore. If
http://trac.osgeo.org/metacrs/browser/sr.org is still the source repo,
last relevant update is from 5 years ago.
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. :)
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
EPSG:9804
<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=> 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:
Code:
EPSG::2010.058
Reporter:
Jay Hollingsworth; Schlumberger
Request:
Review Mercator and Oblique Mercator method names
Actions Taken:
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.
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.
Best regards,
Pepijn
André
_______________________________________________
gdal-dev mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/gdal-dev
