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

[Martin Davis]

Good point!   As Landon pointed out off-list, this should be listed as a 
third option. 

Option #3: specify axis order (or ordinate type/meaning) explicitly in 
the CS Test file format
Pros:
- no room for ambiguity!
Cons:
- more complexity in Test reading code

Is it possible to vote between three options with only three vote 
values?  8^)


Landon Blake wrote:
> 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