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

[Landon Blake]

Martin wrote: "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."

This sounds reasonable. It is really just a matter of duplicating some
simple text files, after all.

Landon
Office Phone Number: (209) 946-0268
Cell Phone Number: (209) 992-0658

Landon
Office Phone Number: (209) 946-0268
Cell Phone Number: (209) 992-0658
 
 

-----Original Message-----
From: metacrs-bounces at lists.osgeo.org
[mailto:metacrs-bounces at lists.osgeo.org] On Behalf Of Martin Davis
Sent: Wednesday, November 04, 2009 12:42 PM
To: Frank Warmerdam
Cc: metacrs at lists.osgeo.org
Subject: Re: [MetaCRS] Standard (and simple) format for conversion
tests.

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

_______________________________________________
MetaCRS mailing list
MetaCRS at lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/metacrs


Warning:
Information provided via electronic media is not guaranteed against defects including translation and transmission errors. If the reader is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this information in error, please notify the sender immediately.