[Esip-documentation] Geospatial Bounds

[Jim Biard via Esip-documentation]

Hi.

I continue to believe that the file-level bounds attributes should, at 
minimum, be limited in terms of what coordinate systems are considered 
acceptable. I did some research and found that EPSG does, in fact, 
declare that latitude is axis 1 and longitude is axis 2, but it floors 
me that they would make geographic coordinates a 'left-handed' 
coordinate system, with all of the corresponding complexity it 
introduces. And strictly speaking, this means that x is latitude and y 
is longitude, not that the ordering in the WKT polygon is y, x. I saw 
that WMS specified a right-handed ordering until the latest version.

As much as it gives me heartburn, there's no way I'm going to turn that 
ship around, so I'll grit my teeth and withdraw the objection to the 
ordering in the polygon.

I would still like to hear a good argument for why we should allow 
free-form coordinate systems in the geospatial bounds attributes.

Grace and peace,

Jim

On 10/8/14, 10:24 AM, Bob Simons - NOAA Federal via Esip-documentation 
wrote:
>
> On 2014-10-07 5:35 PM, Aleksandar Jelenak via Esip-documentation wrote:
>> Bob,
>>
>> On 10/7/14, 7:32 PM, "Bob Simons - NOAA Federal"<bob.simons at noaa.gov>
>> wrote:
>>> 2) The ordering of values for each point in the WKT: x,y vs y,x. My
>>> reading the definitions of WKT indicates that it is always x,y(,z) and
>>> never y,x. I understand that some CRSs have a y,x ordering in certain
>>> circumstances, but I'm not convinced that applies to WKT which always
>>> says x,y. Again, ACDD can choose to be clear about this and specify that
>>> it is always x,y ordering.
>> What is x? What is y? The meaning of both is not determined until their
>> CRS is known.
> That is exactly my point. While the data provider only needs 
> information about one CRS (and is probably intimately familiar with 
> it), the data consumer needs to have access to information about all 
> the CRSs that exist and do some research to understand what the values 
> are and perhaps even the x,y vs y,x ordering. Good luck with that.
>
> I can see you really want this (and presumably have some real need for 
> this) and want to make it sophisticated. I withdraw my objection.
>
>
>> 	-Aleksandar
>>
>> _______________________________________________
>> Esip-documentation mailing list
>> Esip-documentation at lists.esipfed.org
>> http://www.lists.esipfed.org/mailman/listinfo/esip-documentation
>
> -- 
> Sincerely,
>
> Bob Simons
> IT Specialist
> Environmental Research Division
> NOAA Southwest Fisheries Science Center
> 99 Pacific St, Suite 255A
> Monterey, CA 93940
> Phone: (831)333-9878 (Changed 2014-08-20)
> Fax: (831)648-8440
> Email: bob.simons at noaa.gov
>
> The contents of this message are mine personally and
> do not necessarily reflect any position of the
> Government or the National Oceanic and Atmospheric
> Administration.
> <>< <>< <>< <>< <>< <>< <>< <>< <>< <><
>
>
>
> _______________________________________________
> Esip-documentation mailing list
> Esip-documentation at lists.esipfed.org
> http://www.lists.esipfed.org/mailman/listinfo/esip-documentation

-- 
CICS-NC <http://www.cicsnc.org/> Visit us on
Facebook <http://www.facebook.com/cicsnc> 	*Jim Biard*
*Research Scholar*
Cooperative Institute for Climate and Satellites NC <http://cicsnc.org/>
North Carolina State University <http://ncsu.edu/>
NOAA's National Climatic Data Center <http://ncdc.noaa.gov/>
151 Patton Ave, Asheville, NC 28801
e: jbiard at cicsnc.org
o: +1 828 271 4900




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.esipfed.org/pipermail/esip-documentation/attachments/20141008/5683eb3c/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: cfagihga.png
Type: image/png
Size: 11847 bytes
Desc: not available
URL: <http://www.lists.esipfed.org/pipermail/esip-documentation/attachments/20141008/5683eb3c/attachment-0001.png>