[MetaCRS] 'FOSS Maintained' Source of CRS Definitions

[Dean C.Mikkelsen]

Hi everyone,

I can talk with Jim Cain at the APSG/EPSG/OGP and see how 
we can work towards what Norm mentions near the end of his 
e-mail.

I know the members of the EPSG quite well (as I've worked 
with them directly over the years) when I was with 
Schlumberger in Europe and the US.

I am now back in the oil & gas industry on a full-time 
basis (at WorleyParsons Geomatics) - so I'm running into 
this issue and coordinates again.

Norm is correct, there are concatenated transforms that 
don't go through WGS84. I've always worked with the idea 
of concatenated transforms as a map or a route, that could 
be defined within a database structure based on a few 
tables.

We also have to consider the various grid transformations 
(such as in South Africa, New Zealand, etc.) - in many 
cases though the structure has followed CNTv2 and is a 
quasi-standard in grid transformations worldwide.

Cheers,
Dean



On Mon, 12 May 2008 12:52:53 -0700
  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

Dean C. Mikkelsen, B.Sc., P.Eng.

E-mail: dcmikkelsen at terraetl.com

http://www.terraetl.com