[MetaCRS] 'FOSS Maintained' Source of CRS Definitions

[Richard Greenwood]

Nice read Norm, thanks, I learned a lot. It seems like there are two
different approaches, or issues, being discussed in this thread.
Unique identifiers, and parameter definition systems. EPSG provides a
unique identifier that points into a complex, proprietary database.
WKT and GML/XML attempt to provide all the parameters that are
required for a transform.

The EPSG unique identifier provides a concise, relatively unambiguous
definition that can be easily passed between various software. But
it's thin on flexibility.

The verbose WKT style can quickly become ambiguous and is difficult to
parse. On the plus side, it is often more self-contained, and more
readily customizable.

I'd be interested in your comments on my two favourite CRS definition
systems: the Autodesk style unique identifier e.g. "UTM83-12" and the
proj4 parameter definitions.

Rich



On Mon, May 12, 2008 at 1:52 PM, Norm Olsen <norm.olsen at autodesk.com> wrote:
> 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.
>
>
>
>  _______________________________________________
>  MetaCRS mailing list
>  MetaCRS at lists.osgeo.org
>  http://lists.osgeo.org/mailman/listinfo/metacrs
>



-- 
Richard Greenwood
richard.greenwood at gmail.com
www.greenwoodmap.com