[MetaCRS] Standard (and simple) format for conversion tests.

[Martin Davis]

Sorry, this should have gone to the list.

Agreed, it would be nice to keep the number of CRS languages to a minimum.

Perhaps the mapping could be done separately to the actual unit test, to 
keep the unit test file format reasonably simple.  This is essentially 
what CSMap does - it has a separate CVS file mapping between a whole set 
of CRS systems.  I imagine every lib will end up with its own custom set 
of mappings.

On further reflection, perhaps the idea of having an authority prefix 
string could also be accomplished by simply having separate test files 
for each authority.  (Similar to how PROJ4 represents its CS registry, 
with separate files for epsg, esri, etc).  That might make it a bit 
easier for different projects to use only the unit tests they are 
capable of ingesting.  Also keeps the file sizes more manageable, and 
allows a (minor) simplification to the file format by eliminating the 
prefix string.

Martin


Frank Warmerdam wrote:
> Martin Davis wrote:
>> That looks pretty good to me, Frank.
>> It would be nice to have the format of this data in an easy-to-parse 
>> format.  CSMap uses CSV, which certainly meets this criteria (but 
>> maybe fails the readability test).  The format you give is a bit more 
>> work, but maybe not impossible to deal with.  And of course there's 
>> always XML....  Keeping to a single-table structure would be highly 
>> preferable, I think.
>
> Martin,
>
> I wasn't proposing my format which is really just a Python structure.
> I think XML might be nice in that it could be formatted to be more 
> readable
> than a csv with lots of free text.  Ultimately the entries will likely be
> hand created.
>
>> As for CS definition, I'm beginning to appreciate what a can of worms 
>> that is!  My temptation would be to be highly pragmatic about this.  
>> I think a minimum is to have the notion of an authority and a code 
>> (eg "epsg:12345" or "esri:3333").  This could be extended to allow 
>> descriptions as well as code (eg "proj4:+proj=utm +zone=11" or 
>> "Oracle-WKT:-----").  I think this encapsulates enough information 
>> about the "language" being used to describe the CS to allow most libs 
>> to grok the CSes they know about.
>
> This is a reasonable approach, though ideally there would not be many
> CRS languages used as it limits the universality of the test.
>
> I could imagine a way of providing a CRS *override* for a particular
> package.  So for instance if EPSG:3785 is not properly supported by
> PROJ.4 it would be nice to be able to specify the PROJ.4 string that
> it ought to use as an override.  To me this level of flexibility suggests
> XML.
>
> Hmm, I see this wasn't on the list.  Any particular reason?
> Feel free to forward my response on list.
>
> Best regards,

-- 
Martin Davis
Senior Technical Architect
Refractions Research, Inc.
(250) 383-3022