[MetaCRS] Re: Introduction]]

[Frank Warmerdam]

Rutger Bezema wrote:
> Hi Frank, 
> 
> Frank Warmerdam wrote:
>> You make this sound like the backend providers are being invoked at runtime,
>> in which case I would think that implementation language would matter!
> 
> Not if bindings for the language in question were provided.

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.

>> 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?

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 had been thinking of something more along the lines of GML dictionaries
but that isn't set in stone.

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