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

Wed Nov 4 16:18:42 EST 2009

Norm wrote: " If the definition has an EPSG equivalent, than that ID
should be used.  Thus, the test file would also verify that whatever
library is being tested can properly map the EPSG code to a definition
correctly in addition to the actual coordinate conversion.  This will be
of great value in and of itself.  (Name/ID/Definition mapping is a
project unto itself now: SpatialReference.org; is it not?)

Otherwise, maintenance of the test file will be a nightmare, and the
mapping of names/ID/definitions will be such a big problem the primary
purpose of the project will suffer badly.

I suspect that all libraries will support things for which there is no
EPSG number.  If a test application cannot map the "official" CRS
reference (the CRS reference chosen by the committer who added the test
to the database), it either skips the test or the tech lead for that
project adds another copy of the test (perhaps with the same test
number/name) with a CRS reference it can interpret.

If we have more than one file, maintenance will be a big problem.  As we
are all volunteers, that implies the maintenance _may_ not get done at
all."

I think just starting out with EPSG code as the primary identifier would
be better than our current situation, which is everyone cooking their
own bowl of stew.

Perhaps we do that, and then come up with a mapping system for those
libraries that want to support CRS without an EPSG code.

Norm wrote: " NOTE: A single .CSV file maintained in Subversion and
therefore under version control is my preferred manner for this
database.  Once I get the .CSV out of Subversion, I can use Excel,
Access, MySql, Python, Pearl, vi, Notepad, whatever I want to make my
changes.  I simply convert back to .CSV to before committing the
changes.  To me, this means one less contentious issue for us to agree
upon."

I think we might run into trouble trying to cram everything into a
single CSV file for all tests. Using single files makes things a little
more modular, and they can still be managed in a version control
repository.

I might even be able to whip up a little Java library and GUI to edit
the test data files.

However, if the guys want a monolithic CSV, I'll work on a monolithic
CSV.

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

-----Original Message-----
From: Norm Olsen [mailto:norm.olsen at autodesk.com] 
Sent: Wednesday, November 04, 2009 1:13 PM
To: Landon Blake; Martin Davis; Frank Warmerdam (External)
Cc: metacrs at lists.osgeo.org
Subject: RE: [MetaCRS] Standard (and simple) format for conversion
tests.

If the definition has an EPSG equivalent, than that ID should be used.
Thus, the test file would also verify that whatever library is being
tested can properly map the EPSG code to a definition correctly in
addition to the actual coordinate conversion.  This will be of great
value in and of itself.  (Name/ID/Definition mapping is a project unto
itself now: SpatialReference.org; is it not?)

Otherwise, maintenance of the test file will be a nightmare, and the
mapping of names/ID/definitions will be such a big problem the primary
purpose of the project will suffer badly.

I suspect that all libraries will support things for which there is no
EPSG number.  If a test application cannot map the "official" CRS
reference (the CRS reference chosen by the committer who added the test
to the database), it either skips the test or the tech lead for that
project adds another copy of the test (perhaps with the same test
number/name) with a CRS reference it can interpret.

If we have more than one file, maintenance will be a big problem.  As we
are all volunteers, that implies the maintenance _may_ not get done at
all.

NOTE: A single .CSV file maintained in Subversion and therefore under
version control is my preferred manner for this database.  Once I get
the .CSV out of Subversion, I can use Excel, Access, MySql, Python,
Pearl, vi, Notepad, whatever I want to make my changes.  I simply
convert back to .CSV to before committing the changes.  To me, this
means one less contentious issue for us to agree upon.

Norm

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

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.
_______________________________________________
MetaCRS mailing list
MetaCRS at lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/metacrs