[MetaCRS] Using CS-Map to retrieve WKT for EPSG CRS codes: Help?

[Christopher Schmidt]

On Wed, Dec 17, 2008 at 11:27:25AM -0800, Norm Olsen wrote:
> Hello Christopher . . .
> 
> >> I do see that there *is* an entry in my NameMapper.csv:
> >>
> >>  2000,16,EPSG,2000,"Anguilla 1957 / British West Indies Grid",0,0,0,0,,
> The design of the NameMapper.csv file is such that additional flavors
> can be added without code changes.  (An objective which has not yet
> been tested.)  Thus, the entry you speck of simply indicates that EPSG
> has such a definition with a code value of 2000.  If there was an
> additional entry of:
> 
>         2000,16,CSMAP,0,"Anguilla57.BWIGrid",0,0,0,0,,
> 
> This would indicate that the CS-MAP equivalent would be
> "Anguilla57.BWIGrid".  I believe CS-MAP does have a definition for
> this system, but in the merge of Mentor and Autodesk versions of the
> dictionaries, the name mapper entry never got made.

Yeah, I started to understand a bit more when I rewrote my code in
Python; having a REPL loop really helps me out a ton, since I'm very
much used to being able to do quick guess+check against my function
calls.  

> >> Right now, what i'm trying to do is figure out the 'best' answer for a string of WKT attached to any given EPSG CRS ID.
> Good luck.  As you are aware, there are several vendors producing WKT,
> and there is little in the way of a standard.  Also, several of these
> vendors consider some or all of the others as competitors, so they are
> reluctant to adopt a another vendors flavor as a standard.  Thus,
> CS-MAP tries to process them all, and hole that got dug with effort is
> pretty deep right now.

Understood. My hope is not really about producing a single-best, to be
honest, but instead, producing one that we can use by default -- which
can be exported to the various other libraries. In the end, I expect
that the list on a spatial reference's page
(http://spatialreference.org/ref/epsg/2032/) will become as long as my
arm -- but so long as a person who knows a database name + SRS
identifier can get the format they care about out, hopefully all will be
good :) The various Flavours from CS-Map are clearly a step in this
direction (though my CS-Map skills are not yet sufficient to actually
use it, I'm hoping to get there). 

CS-Map working on this effort on its own is probably part of the reason
the hole got built; one of the things I'm learning via SR.org is just
how much bringing things to light lets people share information and
perspectives. :) 

Clearly, we're not going to convince Oracle to go around changing their
parameter names -- at least not overnight. However, it seems to me that
we may be able to come up with *some* agreement on a standard 'lingua
franca' of WKT that the open source tools can speak... and from there,
hopefully tools can do whatever they need to do. 

It seems that the current 'Epsg', 'Ogc', and 'GeoTools' flavors of WKT
in CS-Map could perhaps become the same. I'm also sure that we could
argue all day over what it *should* be, but that's what Open Source
development is all about. :) 

> >> In addition, we are hoping to extend our dictionaries to support the various Oracle dictionaries as well
> Again, good luck.  There are now two distinctly different versions of
> Oracle WKT.  Who knows, maybe they are working on a third!

Understood; my concern is more (at the moment) with getting the
databases that Oracle uses to provide Well-Known IDs out and in the
open (in a similar way to what we have done for EPSG): once that is the
case, there can at least be wider knowledge about them, and people who
don't ahve access to the Oracle DBs (yours truly, and many other Open
Source developers) can *see* what's in there, even if we can't really
understand it. :)

If we can come up with a generally-agreed definition that fits the open
source world, which the various libraries (like OGR, CS-Map, GeoTools)
can read, we can then export flavors for everyone *else* from that
input... I hope. 

> 
> >> What aspect of it [WKT] is a pain?
> There are two issues.  First is the different variations which extends
> beyond just the names of things.  For example, there are different
> parameterizations of different projections.  Another example, in
> Oracle 10, the WKT PROJECTION element does not contain a projection
> name, it contains an EPSG operation code (not an EPSG projection code,
> an OPERTAION CODE).  

This doesn't seem too terrible; at least EPSG does publish their
operation codes? I'm assuming you mean something like the 9802
corresponding to: 

  9802 | Lambert Conic Conformal (2SP)

Honestly, I don't find this to be as personally difficult as cases where
the WKT has been "humanized" -- (2SP) turned into "2 Standard Parallels"
-- the former is at least programatic.

> Second, the datum definition capabilities of WKT are almost useless.
> Yes, you can put a TOWGS84 element in, but this is a very vague
> definition, and does not apply to most of the work done in serious GIS
> systems (i.e. NADCON, NTv2, HARN, CSRS, etc. etc.)

> My guess is that 60+% of all GIS work is based on these datums for
> which there is no means of representation in WKT.  

I'd find that somewhat surprising, personally. Maybe I'm biased -- I am,
after all, just a 'neogeographer' -- but I've not yet interacted with
any data that I couldn't convert using proj4 text. I *think* what you're
saying is that my view is hopelessly narrow :)

> Also, the TOWGS84 element provides no information about the
> transformation technique: Bursa/Wolf, Seven Parameter, Coordinate
> Frame, Position Vector????

Well, the OGC Spec on Coordinate Transformations says:

"This indicates a list of up to 7 Bursa Wolf transformation parameters.
These parameters can be used to approximate a transformation from the
horizontal datum to the WGS84 datum.  However, it must be remembered
that this transformation is only an approximation." (It also gives ome
more information on the 3/6 parameter cases.) I don't know enough to
argue anything about this, but it seems like the definition there says
something about them being Bursa/Wolf... though I have no idea if that's
actually the case :)

> Using the wrong transformation technique can easily put you more than
> a couple of meters off.  And, of course, there are flavors that use
> different units for the TOWGS84 parameters!!!  The only real thing you
> have to work with is the datum name; a name that is different for each
> vendor that produces WKT. 

It doesn't seem impossible for the MetaCRS project to take on the task
of starting to at least write these differences down. CS-Map has already
got what appears to be a decent start on things of this sort, and there
appears to be a non-infinite number of these datums, so it's a possible
(if difficult) task.

> Thus, to accurately process a WKT string on input, you need to
> determine the flavor of the WKT if you're going to _confidently_ map
> the datum name to something meaningful to the host application.

Absolutely. That is a serious problem: one that (in my opinion) gets
much better with shared effort and more light on the situation. Right
now, SR.org makes somewhat of a mess of this, based on my lack of
understanding of the true level of *lack* of cross-WKT shared
information. I assumed that Oracle, ESRI, etc. would be different... but
never assumed that GeoTools and OGR would be so completely opposed. :) 

If we come up with a shared definition of WKT that we -- the
participants in this list -- can agree upon, hopefully it could become a
step towards reducing the babel in at least one direction. 

> Finally, there is no standard way of producing a WKT which is not
> geodetically referenced (i.e. a CRS referenced directly to an
> ellipsoid, or more commonly, directly to a sphere).  Every one has
> their own way of doing this, and some are even inconsistent within
> their own flavor.

Agreed; but again, with enough people working together, maybe we can coe
up with some good ideas here and work to get them spread more widely.
(I'm assuming this is the "Spherical Mercator" problem...) 

> >> Cool; I can't say for sure that I'll be a user of it, but I expect
> >> that it will at least take me longer to search through docs first,
> >> rather than just shooting my mouth off in an email :)
> As the author, of course, I think the documentation is great.  It
> shouldn't be a big deal to convert to a usable form (famous last
> words).

Any documentation at all is a step in the right direction :) 

> >> I've not written any C/C++ code since using the Borland C compiler
> >> on MS/DOS
> That was the environment that CS-MAP originated in: it was called
> Turbo C as I recall, and started off the whole idea of an integrated
> development environment.  I have not really used any language other
> than C or C++ since I switched from (arghhhh!!!) FORTRAN.

Yep, Borland Turbo C++ is the first and only development IDE I've ever  
used. 

Just wait until I've got CS-Map wrapped up nicely in Python; I'll bring
you over to the interpreted side yet :)

Regards,
-- 
Christopher Schmidt
MetaCarta