On 2015-04-13 10:42, Even Rouault wrote:
André,
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,
Do you know if there's a publicly available version of ISO 19162 ? I could
only find this draft on OGC website:
https://portal.opengeospatial.org/files/?artifact_id=54797 ( accessible from
http://www.opengeospatial.org/standards/requests/112?utm_source=emailcampaign219&utm_medium=phpList&utm_content=HTMLemail&utm_campaign=The+OGC+requests+comment+on+the+candidate+standard+Geographic+Information+%E2%80%93+Well+Known+Text+for+coordinate+reference+systems
)
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"
AFAICS, OGC 01-009 is very light on details unfortunatelly (doesn't mention
parameters of all projections), and things have more or less crystalized by
the practice of the various vendors (including GDAL/libgeotiff/proj.4). But
yes, it does mention "Mercator_1SP", and the geopackage spec mentions OGC
01-009 as the standard to use for WKT.
Don't get me wrong, I agree that the OGC WKT is very fragile around the
projection. The other WKT components can be fully defined in the WKT and
their name is really just metadata. My point is that if the WKT produced
by GDAL can use that particular projection name, I expect you are just
pushing the problem further down the line. That is, that WKT string will
eventually get passed to something else that will not understand that name.
I would ask if this is not a bug in the geopackage itself or whatever
created that WKT string.
Not geopackage itself, but the NGA's profile on it. But your point on not
mixing the old OGC 01-009 with ISO 19162 new practice is good, and should
likely be submitted back to NGA.
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.
In an ideal world, everyone would follow standards, and there would not be
many standards/formats to do the same thing ;-) As this world doesn't exist,
GDAL is there to fill in the gaps. I'd say that it is OK to have some ad-hoc
rules to accomodate for data found in the wild (but I'm not sure there has
been data released with the NGA's profile yet ?)
I agree, but a key intention behind standards is to improve
interoperability between different software components. Do you expect
other software components to be able to ingest that WKT string with that
projection name? That is, to be able to read it and use the correct
operation method? How would a WKT implementer know to map that specific
name to the Mercator operation method to use the correct formula? Are
you saying you expect somebody implementing an OGC WKT reader to try to
match the projection name to an operation method name in the
EPSG-registry when trying to determine the operation method to create?
even spatialreference.org
is still using "Mercator_1SP" for the OGC WKT.
spatialreference.org is not really maintained AFAIK, and is partly based on an
old GDAL version. So I wouldn't consider it as an authoritative source.
That's fair, but epsg-registry.org more than likely doesn't offer the
OGC WKT because of these limitations. A better way forward would
obviously be to use the new ISO WKT, but until then this is
unfortunately the mess we all have to deal with.
Even
André
_______________________________________________
gdal-dev mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/gdal-dev
