[wfs-dev] Re: [SFsql.rwg] RE: Axis Ordering in GML - an FYI
Carl Reed OGC
creed at opengeospatial.org
Mon May 23 12:04:34 EST 2005
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
>
>
More information about the wfs-dev
mailing list