[MetaCRS] Re: Introduction]]
Frank Warmerdam
warmerdam at pobox.com
Tue May 20 10:51:57 PDT 2008
Jody Garnett wrote:
> Having access to shared dictionaries would be a good thing; and
> something we could easily slot into GeoTools (while we may not be
> interested in EPSG since we use that database directly).
>
> Dictionaries that would be worth sharing:
> - Authorities like AUTO and AUTO2 from the WMS specification
Jody,
The AUTO WMS projections are a bit more involved than a simple
dictionary, as far as I understand because many of these are
parametric. That is the definition can include additional parameters
for stuff like central meridian. This means it requires more than
just a dictionary. Instead I think it essentially requires code
to valuate the definition and transform it.
> - Additional informal EPSG codes
There is no such thing as an informal EPSG code. What I believe
you mean is additional CRSes informally wedged into the EPSG
space by assigning ids that will hopefully never conflict with
formally assigned ids.
> Frank right now we have an "alias" dictionary that we use when reading
> WKT from a range of sources in order to make it conform to the standard,
> it would be a good candidate to share since it is exactly the kind of
> information that is a pain to build from real world experience.
Yes, absolutely. In OGRSpatialReference-speak I think you are
referring to what I call a "morpher". Basically something that
transforms a flavor of WKT into what I consider standard WKT (but
which is more accurately just OGR WKT). I maintain a morpher for
ESRI PE WKT that is pretty decent. I am also looking at developing
something similar for various versions of Oracle WKT.
>> Well, I would say instead that we should be picking a normalized model
>> that captures all the parts of coordinate system descriptions that
>> we (collectively) have an interest in. And it does seem that a model
>> based on the EPSG database and ISO will satisfy that. But it isn't as
>> simple as saying we will "translate everything to EPSG format". We
>> don't want conflicts with EPSG code spaces, and I suspect we don't
>> want to generate all the EPSG tables. But it is at least plausible
>> that we might generate something essentially like EPSG with some
>> mechanism to disambiguate the code spaces.
> I think you will find that there is no conflict; there is the concept of
> a ReferencedIdentifier (even in the usual WKT format we are all used
> to). The ReferencedIdentifier lists an authority along with a code,
> preventing conflicts. Each authority is responsble for providing the
> definitions for a codespace.
I don't believe that ReferencedIdentifier (aka Authority) appears
in the EPSG tables since everything is implicitly the EPSG authority.
That's why I say I don't think it would be *exactly* the EPSG
tables. We need in some fashion to differentiate. I'd add that
many CRS dictionaries use non-numeric identifiers.
>> I had been thinking of something more along the lines of GML
>> dictionaries but that isn't set in stone.
> Do you have a link to the GML dictionaries; it is not something I am
> familiar with.
Well, there is the GML3 specification of course, and a particular
section on GML CRSes. The new(ish) EPSG registry returns GML
definitions as I understand, though I haven't reviewed it recently.
http://www.epsg-registry.org/
I also distribute a GML definition of a coordinate system last week
as an example of what GML definitions look like, or can look like.
Here is another example, created using OGR:
http://spatialreference.org/ref/epsg/2070/gml/
A dictionary would presumably just be a collection of these,
though likely normalized to refer to objects in other dictionaries
more instead of fully defining things.
Best regards,
--
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up | Frank Warmerdam, warmerdam at pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush | President OSGeo, http://osgeo.org
More information about the MetaCRS
mailing list