[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