FW: [MetaCRS] RE: Initial commit of CSV Test data files

[Landon Blake]

I think that was the design we had before. I had a column that contained
the name/type of ordinate value in the following column.

It looks like we have come full circle. :]

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: Monday, November 30, 2009 1:18 PM
Cc: metacrs at lists.osgeo.org
Subject: Re: FW: [MetaCRS] RE: Initial commit of CSV Test data files

If this kind of metadata is added I would really prefer to see it 
expressed as a separate column(s).  It's much easier to specify and 
process that way.

Martin

Landon Blake wrote:
> In the end, you could add something to the comment column of the test
> data CSV file that clarified the access order. We made the column
names
> generic to add that flexibility, correct?
>
> 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 Frank Warmerdam
> Sent: Monday, November 30, 2009 11:48 AM
> To: Norm Olsen
> Cc: metacrs at lists.osgeo.org
> Subject: Re: [MetaCRS] RE: Initial commit of CSV Test data files
>
> Norm Olsen wrote:
>   
>> Interesting point.  EPSG does specify latitude, longitude, and then
>>     
> height.  My experience says that many (if not most) coordinate system
> libraries use the longitude, latitude, height convention.  That is,
> 99.8% of the time and regardless of whether the coordinate system is
> projective or geographic, the first ordinate increases to the east,
the
> second ordinate increases to the north, and the third ordinate
increases
> away from the center of the earth.  I don't know what the default
> preference for Proj4 is, so I'd be interested in knowing of the
opinions
> of the Proj4 folk on this.
>   
>> Dogmatically, EPSG is correct.  Pragmatically, I believe longitude,
>>     
> latitude, and then height is correct. 
>
> Norm,
>
> PROJ.4 is still "axis orientation ignorant" so it does indeed assume
> long, lat, height for geographic coordinates.  However, the GDAL
> OGRSpatialReference and OGRCoordinateTransformation classes try to
have
> some sort of knowledge of SRS axis ordering though this work is not
> really
> complete at this time.
>
> While I hate the misery that the epsg lat/long axis police have caused
> in this world (mostly via more recent OGC specifications) I am not
sure
> ignoring the EPSG axis definitions is the right thing to do.  I've got
> a foot on either side of this issue and so I've tried not to take a
> position.
>
> In part I suppose it depends on whether our objective is for the test
> data to address broadly defined coordinate system transformations as
> opposed to being primarily focused on projection transformations.  If
> the former then we ought to expect test apps to honour the axis
> definitions
> of the coordinate system. If the latter then sticking to a default
axis
> orientation (perhaps only for geographic coordinates) would be fine.
>
> I can go either way.
>
> 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.