[MetaCRS] Axis order in CS Test file

Norm Olsen norm.olsen at autodesk.com
Mon Nov 30 20:22:50 EST 2009


I'm for Option #2 for the following reasons:

1> The file becomes more useful to me as I hope that I will be able to use test data generated by the Proj4 folk (and others) and they may like to use CS-MAP test data to test their libraries.  A standard ordinate ordering enhances that.  That is, use of a standard ordering convention means that 98% of the 2000+ CS-MAP test cases now become useful to the Proj4 developer, and hopefully, a simplar number of Proj4 test cases become available to the CS_MAP developers.

2> Other users, and possible contributors to the test database, are most likely going to be similar to CS-MAP and Proj4.  As folk who actually have write the coordinate conversion code, and make useful products therefrom, the so called "computer convetion" is the most logical as evidenced by the number and scope of the libraries which have adopted it.

3> I remain unconvinced by the arguments made by the Parameter Dataset folk as they don't actually implement any code to convert coordinates, nor do they produce any products which GIS/Engineering folk use on a daily basis.

I am saddened by the fact that we will not have a clear concise statement about the order of the ordinates.  "Ordinates are ordered as dictated by the respective coordinate reference system definition" is a nice clean statement that makes so much sense.  So, I'll support the effort regardless of which way it goes; but I see a much more useful and valuable result if the ordinate order for geographic coordinates is lng/lat/hgt.

It cannot be denied that there exist coordinate systems out there where the axes are non-standard.  But I think two things about these are generally recognized:

1> In the GIS world, they are a pain in the posterior and in almost everycase, some special features/code are invoked to overcome them, and

2> There will be no new coordinate systems of this type.  I say this because the definers will be GIS users and well aware of the problems associated with a non-conventional axes ordering/directions.

Norm

-----Original Message-----
From: metacrs-bounces at lists.osgeo.org [mailto:metacrs-bounces at lists.osgeo.org] On Behalf Of Martin Davis
Sent: Monday, November 30, 2009 3:38 PM
To: metacrs at lists.osgeo.org
Subject: [MetaCRS] Axis order in CS Test file

I'd really like to get this issue settled, since I'm currently cutting 
code to parse and execute the CS Test file format.  8^)

As I see it a summary of the arguments is:

Option #1 - axis order follows order specified by CS authority
- follows EPSG & OGC convention, which is currently the authority with 
most weight
- simpler for libraries which currently handle axis order explicitly

Option #2 - axis order of geodetic coordinates is always long/lat
- adheres to Principle of Least Surprise (order is consistent between 
src and tgt coordinates)
- simple to document as part of the CS Test format specification
- test format can be interpreted without reference to CS specification
- simpler for libs such as Proj4 and CS-Map which currently work this way

One other thing that to me seems to be in favour of Option #2 is that 
libs which currently handle axis order explicitly should be able to deal 
with this easily (as evidenced by Martin's reply).  Whereas this is not 
so much the case for Option #1 and libs which expect long/lat order.

Shall we put this to a vote?

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


More information about the MetaCRS mailing list