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

Landon Blake lblake at ksninc.com
Tue Dec 1 10:27:40 EST 2009


I'm +1 for option 3.

Landon
Office Phone Number: (209) 946-0268
Cell Phone Number: (209) 992-0658
 
 
-----Original Message-----
From: Martin Davis [mailto:mbdavis at refractions.net] 
Sent: Monday, November 30, 2009 4:09 PM
To: Landon Blake
Cc: metacrs at lists.osgeo.org
Subject: Re: FW: [MetaCRS] RE: Initial commit of CSV Test data files

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



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.


More information about the MetaCRS mailing list