[MetaCRS] 'FOSS Maintained' Source of CRS Definitions

[Norm Olsen]

Hello All . . .

I've been busy earning my rent money, plus a couple days vacation.  Please allow me to respond to the
dozen or so e-mails on this topic with some summary comments:

COMMON DATABASE

ISO 19111 and EPSG (version 6 and later) are essentially the same thing.  While you'll have to cough up $175 to get a copy of 19111, it is a standards document which defines requirements.  EPSG is an implementation of that standard and is available without fee and a rather rational/minimal set of restrictions on its use.  Reasonably good documentation on this implementation is also available on the www.epsg.org site.

Like everything else in this world, EPSG has some pluses and minuses:

+ It is maintained by a well funded and knowledgeable international (mostly European) committee.
+ While every database has some busts, EPSG has fewer, perhaps far fewer, than most.
- EPSG is maintained by the oil industry, so sub-meter accuracy does not concern them greatly.
- Having originated in Microsoft Access, there are some quirky features to the schema as a result.
- The GML generated from EPSG shows, IMHO, some of those quirky features.
- The EPSG database is a parameter database, not designed by a coordinate conversion engineer, and it shows.
- As a parameter database designed to handle the most obscure coordinate systems, it is fairly complex.  It consists of 22 tables (although 3 are devoted to revision management).
+ It is well maintained; new releases come out about every six months and busts are corrected promptly.
+ EPSG codes are widely used and well recognized, and never reused.
+ EPSG's system of deprecation and replacement works fairly well given the very tricky nature of this problem.
- Basically, access to a definition is by code number, rather than name.  Perhaps this is a personal issue.  I prefer a short, easy to remember, easy to type, name.
+ Code values are not language specific, names usually are.

PIVOT DATUM

CS-MAP is designed to use WGS84 as (what I now call) a Pivot datum.  The definitions in the CS-MAP dictionary define a datum as an ellipsoid, a transformation technique, and parameters to convert to WGS84.

+ This approach dies indeed greatly simply things, as the CS-MAP model consists of three rather simple tables, rather than the 22 required by EPSG.

- In the long run, this approach is not sustainable.  There are datums whose only available definition is in terms of another datum and transformation definitions from one datum to another (neither being WGS84), and there are now several WGS84's.  In the long term, we will want our joint effort to produce a system in which multiple transformations are possible (EPSG/19111 refer to this as concatenated transformation).

+ The concatenated approach usually leaves you with several possibilities for getting from one datum to another.  This may be difficult to handle from a User Interface point of view.  This can be overcome by enabling users to define the specific "concatenated path" to be used to get from "here" to "there".

+ A model which supports concatenated transformations increases the complexity of the whole thing.

Well Known Text  WKT

The unfortunate part of WKT is that it is not a standard.  OGC is rather vague and virtually every vendor which produces WKT produces its own variation (I like to call them flavors).  It was mentioned that OGR/GAL has an ESRI morpher, and that it needs an Oracle morpher.  Well, you'll need two Oracle morphers: one for Oracle 9 and another for Oracle 10.  There is just not enough of a standard here to build anything meaningful on.

WKT also has great difficulty in dealing with datums.  WKT generally just gives you a datum name.  Exactly what that name means is different in every flavor.  Thus, without a datum name mapping table, you cannot reliably import WKT unless your application produced it.  If you have a name mapping table, you will also need to have the user specify the WKT flavor so you can map the names correctly; or try to determine the flavor automatically.  For ESRI, a series of GEOTRANS definitions can be found on the web, but they all relate to WGS84 as a pivot datum; which may be determined to be insufficient for our needs (see above).  I have not seen an equivalent of ESRI GEOTRANS for the other flavors.

I suggest that we work towards a clean break with WKT, and support it only to the degree appropriate for legacy use.

XML/GML

It is my sense that most developers have been moving in the XML/GML direction.  My take is that vendors have already developed their own flavors of XML for internal use and support GML as an external thing.  I have done so in my own development with the objective of having a very human readable XML definition which can serve not only as a computer readable definition, but also as meta-data.  The idea being the XML is readable enough to serve as meta-data which can then be cut and pasted into an application and serve as a definition.

Either one (XML/GML) has several advantages over WKT (or the MS Access version of EPSG).  Most important if which is, IMHO, that older releases can read newer XML files without breaking (if coded correctly); and newer code can read older definitions without breaking.  Also, internationalization becomes reasonable.

OPERATIONAL APPLICATION

Establishing an operational site sounds like a nightmare for a volunteer based organization.  OGP/EPSG has established a web based site from which a web client can obtain EPSG definitions in GML form.  EPSG does not support all the definitions we would like.  So I think the appropriate course of action is to establish a working relationship with EPSG and use what they have established and work to get the definitions we require added to the database.

There may be fees involved in using this service, but funds to operate need to come from someplace. :>)

OK, you can wake up now.  I'm done.

Norm Olsen

PS> While the EPSG moniker is still maintained, it is the OGP (Oil and Gas Producers) organization which essentially owns and maintains what we refer to as the EPSG (European Petroleum Survey Group) database.