[MetaCRS] Re: Introduction]]

[Jody Garnett]

Frank Warmerdam wrote:
> Rutger,
>
> The impression I've had from some of the Java projects is that 
> bindings to non-Java components are not very palatable.  I'm afraid I 
> wouldn't be willing to make GDAL or PROJ dependent on call outs to 
> Java for anything I expected to be used much.
It is a mix Frank; bindings to Proj work fine in some contexts (ie when 
you have complete control in a desktop application), and not in others 
(where a Java web application is being "deployed" onto a production server).

If you wanted to port the GeoAPI interfaces to C++ that would be an 
option; but it is up to you to decide if you would gain much from the 
experience? Martin talks about making the interfaces available but has 
thus far not had time.
>>> Some dictionaries (ie. EPSG) will need to be retranslated fairly often.
>>> Others may be fairly static (perhaps a one time utility to generate 
>>> them).
>>> And some (one?) may be essentially manually created with various 
>>> special
>>> case coordinate systems we want to support.
>> thus it would seem to be a logical step to use/choose a dictionary 
>> closely related
>> to the most commonly used. EPSG?
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
- Additional informal EPSG codes

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.
> 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 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.
Jody