[gdal-dev] Add Mercator_variant_A method?

[Andre Vautour]

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é
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20150413/aec7261a/attachment-0001.html>