[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