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

[Christopher Schmidt]

On Tue, Dec 16, 2008 at 05:55:39PM -0800, Norm Olsen wrote:
> Hello Christopher . . .
> 
> Your code is not insane.
> 
> >> Not working projected reference systems: 2000
> 
> There is no equivalent for this EPSG code in the dictionaries and thus there is no entry in the name mapping table.

I'm not sure how what you mean by this: do you mean "This is not in
CS-Map's EPSG database", or something different than that?

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,,

which, I would think, would match to this.

(The EPSG database says:
epsg=# select coord_ref_sys_code, coord_ref_sys_name from epsg_coordinatereferencesystem where coord_ref_sys_code=2000;

  coord_ref_sys_code |            coord_ref_sys_name            
 --------------------+------------------------------------------
                2000 | Anguilla 1957 / British West Indies Grid
                (1 row)

, which seems to match.)

> >> Not working geographic reference systems: 4327
> 
> There is an entry in the mapping table for this EPSG code, but no definition in the dictionary with the name  this EPSG code maps to.

I guess I should try to understand more how this works; it seems that
the aspect I was looking to CS-Map for does not actually exist.

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. There are currently two
libraries that I'm using for this -- GeoTools and OGR -- and I was
hoping to use CS-Map as another piece of information to act as a
comparison. 

In addition, we are hoping to extend our dictionaries to support the
various Oracle dictionaries as well, but that's a longer term task:
solving EPSG as well as possible is hard enough without stacking
additional work on top of ourselves :)  

> There are several thousand definitions of both varieties which do
> work.  These discrepancies are evident as the dictionaries have been
> maintained manually for several years and, as ugly as it might sound,
> by two different individuals working independently.  

Although I was surprised to realize that these are manual, I'm no more
surprised than anything else in this mess of CRS world that exists. :)
Luckily, my initials make me uniquely suited towards the task of
cleaning up the "CRS" mess.

> In the Open
> Source effort, these independent efforts were merged; obviously
> imperfectly.  Work is underway to produce an audit program which will
> locate and report these types of issues.

So, one of the things that the small binary I put together does is make
these kind of errors -- for the EPSG database -- obvious:

  http://crschmidt.net/mapping/csmap/epsg-errors.txt

I'm not sure if these are the type of errors that you're talking,
though.  

> CS-MAP does not support every EPSG system and supports many systems
> which EPSG does not support.  These conditions exist in response to
> the business cases involved in maintaining the product.  The
> aforementioned audit program is intended to bring the dictionary
> compatibility up to EPSG 6.17, and provide the ability to keep it up
> to date relatively easily as new EPSG versions are released.

Understood. Improving this type of interaction is one of the things
we're needing to do with all the pieces we use for spatialreference.org.
My comments are not particularly critical; just trying to help find the
gaps in the various libraries; if they're meant to be there, documenting
them is sufficient, but if they're not, I figure developers should know.

> The test program provided is a good indication if the library has been
> built correctly.  There are some known failures, mostly with the WKT
> feature which has always been a pain.  

What aspect of it is a pain? Just the fact that exporting to WKT is
working with an undefined spec (implemented differently by at least 4
different organizations)? Or is the code itself somewhat problematic?

> These issues need to be dealt
> with, but the Test program was not degraded to eliminate the failure
> reports.   Rather, it represents a good indication of the strengths,
> and weaknesses, of the library.  Actually, I get nervous when a test
> program always produces no errors.  

I typically think of tests as being something that you want to always
behave in the same way; having tests that don't have clearly defined
behavior is one of the things that confuses me. I definitely understand
the desire to have failures in the tests, but when I expect failures, I
change my tests to say something like:

 Tests: Expected 2 failures, got 2 failures, test passed okay

Or something similar; that way, if there are failures I know about, then
someone running them for the first time doesn't have to email a mailing
list asking about them :)

> The repetition in the test
> sequence is indeed intentional.  The earlier tests are repeated to
> verify that a later test did not corrupt something tested by the
> earlier tests.

Understood. I figured that might be the case, but thought that perhaps
it would make sense to have this be an option -- "-2" to double the test
run, for example -- but that's based on the idea that earlier tests
corrupting later tests is rare... something that is possibly not true.  

> There exists substantial documentation for the library in a form
> unsuitable for open source publishing.  Getting this into the
> appropriate form for Open Source publication is also on my list of
> things to do.  I will try to get something useful posted in the very
> near future.

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 :) 

> Thanks for locating the Linux 64 issues.  I do not have access to a 64
> bit Linux machine; your help in this area is greatly appreciated.
> I'll try to get these corrections in pronto.  Do you know what word
> size the Linux 64 bit compiler uses for the "long" type?

No clue. I've not written any C/C++ code since using the Borland C
compiler on MS/DOS, so my experience in this regard is not very large :)
I can, however, offer a shell on a 64-bit machine to build on, if you're
comfortable working via ssh/shell.

Regards,
-- 
Christopher Schmidt
MetaCarta