[wfs-dev] Axis Ordering in GML

Paul Ramsey pramsey at refractions.net
Fri May 20 11:23:04 EST 2005


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!

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



More information about the wfs-dev mailing list