[wfs-dev] Re: [SFsql.rwg] RE: Axis Ordering in GML - an FYI

Steven Keens keens at pcigeomatics.com
Tue May 24 14:30:13 EST 2005


I asked Weisheng here at PCI to look into because I wanted a clear
understanding to see how our software would be affected.  Here are his
findings:


1.  EPSG defines the coordinate system of WGS84 as latitude first and
longitude second. 
2.  WCS clearly describes that its definition of WGS84 BBOX uses WGS84
DATUM, but not use its coordinate system.  It puts the longitude first. 
3.  WFS does not specify which to use thus we assume it to use the
common understanding; it should follow the original definition.  That
means latitude first.
4.  The new OWS common 1.1 specification defines WGS84 as the same as
the WCS's.

>From these findings it is clear that we do not have any consistancy
within the OGC specs.  I think it is vital that the OGC be consistant on
this.  The only way to be consistant is to follow Simon Cox's
suggestion: that the ordering be specified by the original CRS.

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: Carl Reed OGC [mailto:creed at opengeospatial.org] 
Sent: Monday, May 23, 2005 13:05
To: Nicolai, Roel R SIEP-EPT-SCIG; Martin Daly;
wfs-dev at opengeospatial.org
Cc: PostGIS Development Discussion; sfsql.rwg at opengeospatial.org
Subject: [wfs-dev] Re: [SFsql.rwg] RE: Axis Ordering in GML - an FYI

Roel -

Thanks for the clarification and additional information. The following
is not to incite more dicussion but is merely provided as informational
:-)

As this latest discussion on axis order was progressing, I browsed
around the web looking for other standards and products use of
geographics and how the axis were ordered. Kind of a best practices
study. I found that the majority of other standards that express or
encode WGS 84 based coordinates do so as latitude/longitude (see below).

Cheers

Carl

Axis Order best practice:

OASIS CAP: A WGS-84 coordinate value is here represented as a
comma-delimited latitude/longitude pair, measured in decimal degrees
(un-projected). Latitudes range from -90 to 90 and longitudes range from
-180 to 180

OMA MLP API: Example -
  <Point srsName="www.epsg.org#4326" gid="some_thing">

    <coord>

      <Y>30 27 45.3N</Y>

      <X>45 25 52.9E</X>

    </coord>

  </Point>
IETF DHCP Location Draft RFC: Latitude and Longitude are represented in
fixed-point 2s-complement binary degrees, for the economy of a smaller
option size compared to the string  encoding of digits in [4]. Datum is
WGS
84

IETF PIDF Location Draft RFC: example (is GML!)
  <gml:Point gml:id="point96" srsName="epsg:4326">
         <gml:coordinates>31:56:00S 115:50:00E</gml:coordinates>
  </gml:Point>
netCDF: Appears to be Long/Lat :-)

Climate Data Markup Language (CDML): Lat/Long

Portland State University class on CRS: Geographics are expressed at
Lat/Long.

POSC Epicenter Model - Lat/Long

GeoVRML: Either. Lat/Long is the default. GD - "<latitude> <longitude>
<elevation>" or <longitude> "<latitude> <elevation>". The order of
latitude and longitude is controlled by the geoSystem field. If
"latitude_first" is specified, the order is latitude then longitude. If
"longitude_first" is specified, the order is longitude then latitude. If
neither is specified, "latitude_first" is the default.

SEDRIS - Lat/Long

West Virginia GIS Standard best Practices - Lat/Long

Carl Reed, PhD
CTO and Executive Director Specification Program OGC


The OGC: Helping the World to Communicate Geographically

---------------------



This communication, including attachments, is for the exclusive use of
addressee and may contain proprietary, confidential or privileged
information. If you are not the intended recipient, any use, copying,
disclosure, dissemination or distribution is strictly prohibited. If you
are not the intended recipient, please notify the sender  immediately by
return email and delete this communication and destroy all copies.


----- Original Message -----
From: "Nicolai, Roel R SIEP-EPT-SCIG" <Roel.Nicolai at shell.com>
To: "Martin Daly" <Martin.Daly at cadcorp.com>;
<wfs-dev at opengeospatial.org>
Cc: "PostGIS Development Discussion" 
<postgis-devel at postgis.refractions.net>; <sfsql.rwg at opengeospatial.org>
Sent: Monday, May 23, 2005 2:47 AM
Subject: RE: [SFsql.rwg] RE: Axis Ordering in GML


> Gents,
>
> There are two versions of WGS 84 floating around nowadays:
> - EPSG code 4326, which defines latitude before longitude 
> (urn:ogc:def:crs:EPSG:6.6:4326)
> - CRS84, with longitude before latitude
(urn:ogc:def:crs:OGC:1.3:CRS84)
> See OGC document 04-077.
>
> Don't mix these two up or you map will look rather odd.
>
> On the other point I need correct Martin: The EPSG definitions of 
> geographic crs's now specify the units to "degree (supplier to define 
> representation)".
> Hence, it is quite legal for the specification to prescribe decimal 
> degrees in conjunction with the use of EPSG codes, or for the supplier

> provides additional information stating that the coordinate values in 
> decimal degrees if the spec does not mention that.  For example GML 
> prescribes decimal degrees.  What you cannot do is use your own 
> representation of degrees or you own preferred axis order AND:
> 1. not tell anyone about it or agree it in a small group and assume
that 
> is authoritiative for the rest of the world
> 2. overwrite what the spec prescribes.
>
> The sum of it is that if you feel you must use longitude before
latitude, 
> use OGC:CRS84;  DON'T use EPSG:4326, because that means latitude
before 
> longitude.  ANY software that reads "EPSG:4326" should expect that the

> latitude value comes before the longitude value.  If it internally
swaps 
> these values the software makes a joke of the OGC specifications and
of 
> every attempt to standardize.
> The whole idea of standardisation is to agree to do things a certain
way 
> and to avoid one's own preferred solution.  The "one" in the previous 
> sentence may mean an individual person, a data supplier, a working
group, 
> a particular group of users etc.
>
> Best regards,
> Roel Nicolai
>
> -----Original Message-----
> From: sfsql.rwg-bounces+roel.nicolai=shell.com at opengeospatial.org
> [mailto:sfsql.rwg-bounces+roel.nicolai=shell.com at opengeospatial.org]On
> Behalf Of Martin Daly
> Sent: Friday, May 20, 2005 9:19 AM
> To: wfs-dev at opengeospatial.org
> Cc: PostGIS Development Discussion; sfsql.rwg at opengeospatial.org
> Subject: [SFsql.rwg] RE: 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.
>
> Oh no, not again.  Do you *any* idea what you have just started?
>
>> 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?
>
> Cadcorp's experience is that the theory is lat/lon, but the practice
is
> lon/lat.  Another worm squirming out of the can is that the
> representation of ordinates in EPSG 4326 is not supposed to be in
> decimal degrees.  There are differences of opinion (!) as to whether
or
> not this applies to data transfer mediums, or just to user-facing
> representation.
>
> Let battle commence,
> Martin
>
> _______________________________________________
> SFsql.rwg mailing list
> SFsql.rwg at opengeospatial.org
> https://mail.opengeospatial.org/mailman/listinfo/sfsql.rwg
>
>
>
> _______________________________________________
> SFsql.rwg mailing list
> SFsql.rwg at opengeospatial.org
> https://mail.opengeospatial.org/mailman/listinfo/sfsql.rwg
>
> 

_______________________________________________
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