[wfs-dev] Axis Ordering in GML

Fri May 20 11:33:40 EST 2005

We have a WFS client and have dealt with this issue by assuming that the
data is ordered according to CRS' specification.  If the server happens
to invert the axes then the data is rotated in our client.  We recognize
that our customers will likely send us bug reports but we don't want to
add special cases to our client.  In such cases we will tell our clients
that it is a problem with the WFS server and to complain to the server's
administrator.  Who's reputation will be tarnished:  PCI's, the WFS
server's, or the OGC's?  I think a little of each.  If it happens too
often then people will start questioning the pertinance of the OGC and
maybe start looking for other solutions.

Cheers,
--
Steven Keens
PCI Geomatics Inc.	http://www.pcigeomatics.com/
Web Architect/OGC Technical Representative

The highest courage is to dare to appear to be what one is.
              - John Lancaster Spalding

-----Original Message-----
From: Paul Ramsey [mailto:pramsey at refractions.net] 
Sent: Friday, May 20, 2005 12:07
To: Simon Cox
Cc: wfs-dev at mail.opengeospatial.org
Subject: Re: [wfs-dev] Axis Ordering in GML

Geoserver also does the "wrong" thing. Geoserver passes the CITE tests. 
Geoserver is therefore (as far as the implementors can tell)
"conformant".

This detail of implementation is sufficiently obscure that implementors
seem to be universally failing to do it. So either the specs need a big
red warning message on the front, or the OGC needs to adopt the
implementation bias (easting/northing) as official and (again) say so in
every spec.

I really could care less about the issue in terms of which way is the
"one true way" I just want everyone to implement the same damn thing so
I can write a client that interoperates with everybodies servers and
doesn't need special-cases to determine the vendor and behavior for
every WFS under the sun.

P.

Simon Cox wrote:
> Not legal because it suggests a latitude of -172.335 when the 
> permissible range for latitude in EPSG:4326 is 90:00:00.00S - 
> 90:00:00.00N, etc etc.
> 
> Strictly this is *not* a GML issue - the gml:coordinates element is 
> merely a character string, so the example is "valid" XML/GML.
> Its just that the example given is strictly meaningless.
> It is a "truth in advertising issue" - if you claim to be using a 
> particular reference system, and then the value you provide is 
> ill-formed & out of range, then you are *not* really using that CRS.
> 
> Unfortunately the three WFS's are telling porkies!
> The sooner they stop then the sooner we could put this one to bed.
> 
> Simon
> 
> ----- Original Message ----- From: "Paul Ramsey" 
> <pramsey at refractions.net>
> To: <Simon.Cox at csiro.au>
> Cc: <wfs-dev at mail.opengeospatial.org>
> Sent: Friday, May 20, 2005 10:21 PM
> Subject: Re: [wfs-dev] Axis Ordering in GML
> 
> 
>> Quick clarification:
>>
>>   Not legal in GML3 or in GML2 (WFS 1.0) or both?
>>
>> It is GML2 I am concerned about. I have results from three WFS 
>> servers so far (Mapserver, Cubewerx, Intergraph) and all are 
>> returning 4326 data in easting/northing order. A de facto 
>> implementation standard seems to be emerging. I want to hear what 
>> implementors have done for WFS 1.0, if possible!
>>
>> Thanks,
>>
>> Paul
>>
>> On 19-May-05, at 6:33 PM, <Simon.Cox at csiro.au> wrote:
>>
>>> No - it is not legal.
>>> The main reason is the one you identify - as will all other 
>>> coordinate reference system definitions, EPSG 4326 does specify the 
>>> axis order, and as with all traditional geographic systems, the axis

>>> order is latitude-longitude.
>>> Furthermore, I think 4326 specifies DMSH as the encoding, though 
>>> this aspect might have been relaxed.
>>> It is in fact not a GML issue, but is an EPSG issue.
>>> GML inherits the rules provided by the organisation that are 
>>> providing the definition of the CRS.
>>>
>>> Two other issues:
>>> 1. "EPSG:4326" is not a valid URI. In Document 05-010 OGC has 
>>> defined a URN scheme that is defined to refer to thing that you are 
>>> trying to point to. In this case it would be 
>>> urn:ogc:def:crs:EPSG:6.3:4326 2. the gml:coordinates element is 
>>> deprecated in GML 3.0 and beyond. Use gml:pos instead, with spaces
between the components instead of comma.
>>>
>>> Simon
>>>
>>>> -----Original Message-----
>>>> From: wfs-dev-bounces+simon.cox=csiro.au at opengeospatial.org
>>>> [mailto:wfs-dev-bounces+simon.cox=csiro.au at opengeospatial.org]
>>>>  On Behalf Of Paul Ramsey
>>>> Sent: Thursday, 19 May 2005 11:50 PM
>>>> To: wfs-dev at mail.opengeospatial.org
>>>> Subject: [wfs-dev] Axis Ordering in GML
>>>>
>>>> Question for the group. Is the GML below legal?
>>>>
>>>> <gml:Point
>>>> srsName="EPSG:4326"><gml:coordinates>-172.335,18.53916667</gml
>>>> :coordinates></gml:Point>
>>>>
>>>> I have built a GML point that references EPSG:4326 but has the 
>>>> easting before the northing.
>>>>
>>>> If I check your WFS 1.0 servers, will I find them returning GML in 
>>>> easting/northing order or northing/easting order for EPSG:4326? 
>>>> This is both a theory and practice problem. In theory, what should 
>>>> happen, and in practice, what are people doing?
>>>>
>>>> Paul
>>>> _______________________________________________
>>>> wfs-dev mailing list
>>>> wfs-dev at opengeospatial.org
>>>> https://mail.opengeospatial.org/mailman/listinfo/wfs-dev
>>>>
>>
> 
> _______________________________________________
> wfs-dev mailing list
> wfs-dev at opengeospatial.org
> https://mail.opengeospatial.org/mailman/listinfo/wfs-dev

_______________________________________________
wfs-dev mailing list
wfs-dev at opengeospatial.org
https://mail.opengeospatial.org/mailman/listinfo/wfs-dev