[Esip-documentation] ACDD 1.3 issue: geospatial_bounds, geospatial_vertical_units - x y vs. y x ordering
Bob Simons - NOAA Federal via Esip-documentation
esip-documentation at lists.esipfed.org
Tue Oct 14 13:17:15 EDT 2014
After some research, I think I have resolved my own confusion and can
provide an explanation for why longitude latitude ordering is used in
Well Known Text (WKT) Geometries in some situations and latitude
longitude ordering is used in other situations (notably, different
software), even for the same Coordinate Reference System (CRS), e.g.,
EPSG:4326.
(Yes, I'm now talking about lon lat vs lat lon ordering, not x y vs. y x
ordering that I originally wrote about.)
Below is my current understanding of the situation. If I'm wrong or
making a mistake, please let me know.
I would have preferred to do more research but I'm writing this now
since the telecon is in a few hours.
The short answer is: Now (that's important), the official OGC ordering
in WKT Geometries is CRS-dependent. So, e.g., for EPSG:4326, the order
is lat lon.
---
The chain of reasoning for that starts with the WKT Geometry
specification in:
(OGC's
06-103r4_Implementation_Specification_for_Geographic_Information_-_Simple_feature_access_-_Part_1_Common_Architecture_v1.2.1.pdf
dated 2011 and downloadable at http://www.opengeospatial.org/standards/sfa )
in section 6.1.2.1
"The interpretation of the coordinates is subject to the coordinate
reference systems associated to the point. All
coordinates within a geometry object should be in the same coordinate
reference systems. Each coordinate shall
be unambiguously associated to a coordinate reference system either
directly or through its containing geometry. "
and more specifically in definition: "4.6
coordinate system
set of mathematical rules for specifying how coordinates (4.3) are to be
assigned to each point (4.17)
[ISO 19111]" That's the entire definition.
As an ISO standard, ISO 19111 costs a substantial amount to purchase
(CHF 178).
Fortunately, Wikipedia
(http://en.wikipedia.org/wiki/Spatial_reference_system)
says "ISO 19111:2007 Geographic information---Spatial referencing by
coordinates, [is] also published as OGC Abstract Specification, Topic 2:
Spatial referencing by coordinate."
OGC's
08-015r2_The_OGC_Abstract_Specification_Topic_2_Spatial_referencing_by_coordinates.pdf
(written by Roger Lott in 2010 and accessible as Topic 2 at
http://www.opengeospatial.org/standards/as)
says in section "6.1 Relationship between coordinates and coordinate
reference system":
"Coordinates are ambiguous until the system to which those coordinates
are related has
been fully defined. Without the full specification of the system,
coordinates are
ambiguous at best and meaningless at worst. A coordinate reference
system (CRS)
defines the coordinate space such that the coordinate values are
unambiguous. In this
Abstract Specification, the order of the coordinates within the
coordinate tuple and their
unit(s) of measure shall be parts of the coordinate reference system
definition."
The definition for "coordinate tuple" reiterates this:
"4.12
*coordinate tuple*
tuple composed of a sequence of coordinates
NOTE The number of coordinates in the coordinate tuple equals the
dimension of the coordinate system; the
order of coordinates in the coordinate tuple is identical to the order
of the axes of the coordinate system."
So you have to look at the definition of a given CRS to find the axis
ordering.
For example, use "retrieve by code" at
http://www.epsg-registry.org/ to search for Code: 4326.
Then expand the "Ellipsoidal CS" section to see the Axis Order:
1 Geodetic latitude
2 Geodetic longitude
---
But that doesn't explain the clear usage of lon lat ordering for WKT
Geometries by big time software programs like SQL Server and PostGIS,
the spatial add-on for PostgreSQL.
I think the explanation is on the GeoTools (OSGeo) web page on Axis Order:
http://docs.geotools.org/latest/userguide/library/referencing/order.html
It is worth reading the entire web page, but the important quotes are:
"*Axis Order*
Computer scientists and geographers disagree about one of the basic
tenants of geography. "
"*The problem*
In the EPSG database, 4326 maps to a geographic CRS with (latitude,
longitude) axis order. However, most software in the field understand
EPSG:4326 as a geographic CRS with (longitude, latitude) axis order,
because legacy OGC specifications were designed that way. The problem is
not limited to EPSG:4326; it applies to most geographic CRS defined in
the EPSG database. The axis order understood by currently existing
software is in violation with what the EPSG database said.
Prior to the June 2005 [OGC] meetings, there was considerable email
dialogue between OGC members regarding axis order and coordinate
reference systems. After some discussion, the members in attendance
agreed that going forward, for new specifications, coordinate values
shall be listed in the axis order specified by the referenced coordinate
reference system (CRS). However no clarification was ever gained on what
the situation with existing specifications was. The
reality-on-the-ground is that every WFS 1.0 implementation tested that
advertised EPSG:4326 as its CRS returned data on (longitude, latitude)
order."
So basically, it appears like OGC supported longitude latitude ordering
before 2005 and CRS-dependent ordering (usually latitude longitude)
after 2005, sowing the seeds of confusion for everyone. And even though
one must read multiple OGC specifications (at ~100 pages each) and
numerous web pages to try to figure out one OGC specification, it is
hard to be certain about even fundamental aspects of the system like
latitude longitude ordering. A single carefully constructed example in
the WKT Geometry specification could have clarified the situation (e.g.,
showing a longitude value <-90 or >90), but all I found were ambiguous
examples, not tied to any CRS, e.g.,
Point (10 10)
LineString ( 10 10, 20 20, 30 40)
Polygon ((10 10, 10 20, 20 20, 20 15, 10 10))
---
That's that best I've been able to figure out so far.
Again, if I misunderstood something, please let me know.
I'm sorry. Many of my previous requests for geospatial_bounds were
misguided/wrong.
So my requests for the geospatial_bounds attribute now are:
* As with other attributes which are "owned" by other groups, if ACDD
uses WKT Geometry, we should respect the owner's specification. In this
case, that is OGC's specification of WKT Geometry and EPSG's and others'
specifications of various CRS's.
* Have a way to specify the CRS, but specify the default CRS
(EPSG:4326?) in the ACDD specification.
* Give clear examples showing longitude values <-90 or >90.
* State clearly that the order of values for each coordinate is
dependent on the order in the CRS's definition, and give an example.
I think you previous proposed definition had these features.
* If approximate values are allowed, state that.
---
On 2014-10-10 9:31 AM, Bob Simons - NOAA Federal wrote:
> I am thoroughly confused about the x y vs. y x (or lon lat vs lat lon)
> ordering
> within WKT Geometries. Some people assert that the ordering is
> CRS-dependent.
> I'm not disputing that CRS's, in other situations, may have a
> preferred ordering
> (can someone please tell me where they are defined?),
> but I have never read anything that says that that ordering applies to
> WKT.
> Indeed, all of the documentation I can find for WKT only refers to
> x y (lon lat) ordering, but maybe I'm misreading or overlooking the
> important sections.
>
> Below are quotes from three documents that refer only to x y (lon lat)
> ordering.
> Can anyone refer me to authoritative documentation that indicates the
> ordering in WKT is CRS-dependent and thus sometimes x y (lon lat)
> and sometimes y x (lat lon)?
>
> Thank you.
>
> ---
> Seeking the most authoritative documentation, I see:
>
> 1) http://en.wikipedia.org/wiki/Well-known_text says
> "The formats were originally defined by the Open Geospatial Consortium
> (OGC) and described in their Simple Feature Access ... specifications"
> So that leads to ...
>
> 2) http://en.wikipedia.org/wiki/Simple_Features refers to
> "OpenGIS Implementation Specification for Geographic information -
> Simple feature access - Part 1: Common architecture (05-126, 06-103r3,
> 06-103r4), current version 1.2.1"
> So that leads to ...
>
> 3) I think this is the most authoritative documentation:
> OGC's
> 06-103r4_Implementation_Specification_for_Geographic_Information_-_Simple_feature_access_-_Part_1_Common_Architecture_v1.2.1.pdf
> (downloadable at http://www.opengeospatial.org/standards/sfa )
> Here are some quotes from it:
>
> "6.1.4.1 Description
> A Point is a 0-dimensional geometric object and represents a single
> location in coordinate space. A Point has an
> x-coordinate value, a y-coordinate value. If called for by the
> associated Spatial Reference System, it may also
> have coordinate values for z and m."
>
> "7.2.2 BNF Productions for Two-Dimension Geometry WKT
> The following BNF defines two-dimensional geometries in (x, y)
> coordinate spaces. With the exception of the
> addition of polyhedral surfaces, these structures are unchanged from
> earlier editions of this standard.
> <point> ::= <x> <y>"
>
> "7.2.3 BNF Productions for Three-Dimension Geometry WKT
> The following BNF defines geometries in 3 dimensional (x, y, z)
> coordinates.
> <point z> ::= <x> <y> <z>"
>
> "7.2.5 BNF Productions for Three-Dimension Measured Geometry WKT
> The following BNF defines three-dimensional geometries in (x, y, z)
> coordinate spaces. In addition, each
> coordinate carries an "m" ordinate value that is part of some linear
> reference system.
> <point zm> ::= <x> <y> <z> <m>"
>
> "8.2.8 Description of WKBGeometry representations
> The Well-known Binary Representation for Geometry is described below.
> The basic building block is the
> representation for a Point, which consists of a number Doubles,
> depending on the coordinate referece system in
> use for the geometry. The representations for other geometric objects
> are built using the representations for
> geometric objects that have already been defined.
> // Basic Type definitions
> // byte : 1 byte
> // uint32 : 32 bit unsigned integer (4 bytes)
> // double : double precision number (8 bytes)
> // Building Blocks : Coordinate, LinearRing
> Point {
> double x;
> double y}
> PointZ {
> double x;
> double y;
> double z} "
>
> The document does not contain these text strings: "y, x" or "<y> <x>"
>
> -----
> The book "Pro Spatial with SQL Server 2012" By Alastair Aitchison
> http://books.google.com/books?id=pHeWWBY3cPEC&pg=PA25&lpg=PA25&dq=wkt+point+syntax&source=bl&ots=STQk8kv__q&sig=aigFxz103N15G4yOCu0lCoXXvKI&hl=en&sa=X&ei=GQM4VPWLPMf7iwK454FA&ved=0CFcQ6AEwCTgK#v=onepage&q=wkt%20point%20syntax&f=false
> the very bottom of page 25 says
> "Defining a Point from geographic coordinates follows the same convention,
> but with one thing to watch out for: whereas in everyday language it
> is common
> to refer to coordinates of "latitude and longitude" (in that order),
> when you
> write geographic coordinates in WKT the longitude coordinate always comes
> first, then the latitude coordinate. The WKT syntax for a geography
> Point located at a latitude of 40º and longitude of 60º is therefore:
> POINT(60 40)
> "
>
> -----
> The MySql 5.7 documentation at
> http://dev.mysql.com/doc/refman/5.7/en/gis-data-formats.html#gis-wkt-format
> says
>
> mysql> SELECT X(POINT(15, 20));
> +------------------+
> | X(POINT(15, 20)) |
> +------------------+
> | 15 |
> +------------------+
>
> mysql> SELECT X(GeomFromText('POINT(15 20)'));
> +---------------------------------+
> | X(GeomFromText('POINT(15 20)')) |
> +---------------------------------+
> | 15 |
> +---------------------------------+
>
> ---
>
>
> --
> Sincerely,
>
> Bob Simons
> IT Specialist
> Environmental Research Division
> NOAA Southwest Fisheries Science Center
> 99 Pacific St, Suite 255A
> Monterey, CA 93940
> Phone: (831)333-9878 (Changed 2014-08-20)
> Fax: (831)648-8440
> Email: bob.simons at noaa.gov
>
> The contents of this message are mine personally and
> do not necessarily reflect any position of the
> Government or the National Oceanic and Atmospheric
> Administration.
> <>< <>< <>< <>< <>< <>< <>< <>< <>< <><
>
--
Sincerely,
Bob Simons
IT Specialist
Environmental Research Division
NOAA Southwest Fisheries Science Center
99 Pacific St, Suite 255A
Monterey, CA 93940
Phone: (831)333-9878 (Changed 2014-08-20)
Fax: (831)648-8440
Email: bob.simons at noaa.gov
The contents of this message are mine personally and
do not necessarily reflect any position of the
Government or the National Oceanic and Atmospheric
Administration.
<>< <>< <>< <>< <>< <>< <>< <>< <>< <><
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.esipfed.org/pipermail/esip-documentation/attachments/20141014/30def418/attachment-0001.html>
More information about the Esip-documentation
mailing list