[wfs-dev] Axis Ordering in GML

Morris, Charles, E. chuck.morris at ngc.com
Fri May 20 14:00:40 EST 2005 

It would be possible to write tests that ensure consistent axis ordering under EPSG:4326 for a specific set of test data.  Perhaps this should be done.  But it is not possible to test axis ordering under all schemes because there are an infinite number of possible schemes.   

Interoperability is not mandated by the WFS spec if it doesn't require implementation of any concrete coordinate reference scheme.  It would be nice if the WFS spec at least recommended a common coordinate system and showed how to use it, but I don't believe it does.  Hence, the interoperability problem.

- Chuck

-----Original Message-----
From: wfs-dev-bounces+chuck.morris=ngc.com at opengeospatial.org
[mailto:wfs-dev-bounces+chuck.morris=ngc.com at opengeospatial.org]On
Behalf Of Allan Doyle
Sent: Friday, May 20, 2005 11:46 AM
To: wfs-dev at mail.opengeospatial.org
Subject: Re: [wfs-dev] Axis Ordering in GML



On May 20, 2005, at 12:23, Paul Ramsey wrote:

> True, but if we consider consistent axis ordering (under any scheme  
> at all!) a proper part of interoperability (and we *should*!) then  
> the CITE tests should exercise that! And they don't! So it is  
> possible for non-interoperable implementations to pass CITE!

But we've already found out that CITE doesn't test interoperability,  
nor does it test conformance to the spec. It tests compliance to the  
*profile* of the spec that was defined for the test itself. See this  
excerpt from wms.rwg:

On Jan 31, 2005, at 11:42, Morris, Charles, E. wrote:

 > Allan Doyle wrote:
 >>>
 >>>  1- To be certifiable as a BASIC WMS, an
 >>>  implementation must meet the following requirements:
 >>> ·It must support image/png or image/gif for GetMap
 >>> requests.
 >>
 >> This is a shortcoming in the conformance test. The WMS spec does not
 >> require either of these formats.
 >>
 >
 > I think there are some misunderstandings here.  The compliance test
 > requirements do not modify the WMS spec.  What they do is define
 > profiles of WMS implementations.  To meet the profile somewhat
 > arbitrarilly called "BASIC", the implementation must support PNG or
 > GIF.  This doesn't imply that implementations that don't meet this
 > requirement aren't conformant to the WMS spec.

So all is not lost. The testers could (should?) define a test that  
ensures interoperability!

     Allan

>
> Paul
>
> PS - Funny note: check out the GML data for the WMS CITE tests. It  
> follows the axis ordering specified in the embedded EPSG reference,  
> which is northing/easting.
>
> Morris, Charles, E. wrote:
>
>
>> All the WFS test data for CITE uses EPSG:32615 so the CITE tests
>> really don't shed any light on the EPSG:4326 interpretation
>> controversy.
>> Chuck Morris Northrop Grumman IT, TASC
>> -----Original Message----- From:
>> wfs-dev-bounces+chuck.morris=ngc.com at opengeospatial.org  
>> [mailto:wfs-dev-bounces+chuck.morris=ngc.com at opengeospatial.org]On  
>> Behalf Of Paul Ramsey Sent: Friday, May 20, 2005 11:07 AM 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
>>
>
> _______________________________________________
> wfs-dev mailing list
> wfs-dev at opengeospatial.org
> https://mail.opengeospatial.org/mailman/listinfo/wfs-dev
>

-- 
Allan Doyle
+1.781.433.2695
adoyle at intl-interfaces.com



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

More information about the wfs-dev mailing list