[MetaCRS] "FOSS Maintained" Source of CRS Definitions

[Landon Blake]

I sent Christopher Schmidt a short e-mail summarizing our discussion and
asking for his comments. I also asked him how the web site accessed the
CRS definitions, and if it used a single consolidates source of CRS
definitions.

I will report back with any response I receive from him.

Landon

-----Original Message-----
From: Mike Adair [mailto:madair at dmsolutions.ca] 
Sent: Wednesday, May 07, 2008 6:02 AM
To: Mateusz Loskot
Cc: Landon Blake; metacrs at lists.osgeo.org
Subject: Re: [MetaCRS] "FOSS Maintained" Source of CRS Definitions

I'm thinking we should approach Chris Schmidt/Howard Butler about their 
http://spatialreference.org site for this.  This provides a RESTful 
service for looking up the definitions, returns the definitions in 
various formats, includes the EPSG database and allows for user-uploaded

definitions too.  Proj4js uses this service for run-time lookup of the 
definitions.

I know that OSGeo is not about running operational services like this, 
we could ensure continued operation of that service.

Mike

Mateusz Loskot wrote:
> Landon,
>
> I'm just an observer and CRS cadet who want to learn more about the
> subject here, but I'd have a few, rather obvious comments.
>
> Landon Blake wrote:
>> I was wondering if there had ever been any effort to consolidate
these
>> different sources of definitions into a single data product
maintained
>> by an "open source" organization like the OSGeo. Maybe this data
product
>> is an XML file, maybe it is a group of text files, or maybe it is
>> something else that I haven't thought of.
>
> IMHO, the first thing would be to define common data model for all 
> types of definitions and their sources. XML, text files, db tables, 
> etc. are just physical representation of a model. If there would be a 
> data model, then, I believe, it was possible to use any type of 
> storage you can think of.
>
>> I suspect each of the different CRS programming libraries has someone
>> that is trying to keep up with changes and additions to the CRS
>> definitions from the different sources mentioned above. I wonder if
>> working together to consolidate multiple CRS definition sources into
a
>> single "FOSS maintained" source might save us all some work.
>
> Yes, there are tools and scripts used in GDAL/OGR and PROJ.4 to
update.
> I think other CRS projects have their own tools.
>
>> There is already a "standard" and open format for CRS definitions,
>> namely WKT, correct? Couldn't this be used? (I know there are
thousands
>> of CRS definitions, but we could use streaming access to a text file,
at
>> least on the Java side of things.)
>
> Perhaps it's a reasonable option. I'm sure there would be need of 
> number of functions morphing between WKT and various formats (see 
> OGRSpatialReference::morphToESRI/morphFromESRI). We've already 
> identified in GDAL/OGR that we need another pair of morphers: 
> morphToOracle/morphFromOracle. It indicates we have to deal with WKT 
> variations.
>
>> At any rate, maybe there is already some type of "single source" for
CRS
>> definitions already in existence. But I thought it didn't hurt to
ask.
>
> AFAIK, there is no common source but I'm sure that a gang of inventors

> of something like that would be blessed :-)
>
>> It would seem that this would be one area that programmers using
>> different languages could cooperate.
>
> I'd list:
> - CRS model spec.
> - CRS interface spec. (not necesary but would be nice)
> - common set of CRS data generators from X known resources to single 
> repository
> - common rules for CRS def. translators, so all import/export 
> operations always result in the same output, independently to 
> implementation.
>
> Greetings


Warning:
Information provided via electronic media is not guaranteed against defects including translation and transmission errors. If the reader is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this information in error, please notify the sender immediately.