Axis Orientation and msOWSCommonBoundingBox()

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Axis Orientation and msOWSCommonBoundingBox()

Frank Warmerdam
Tom,

As we have touched on in the past, for WCS 1.1 I need to honour EPSG
axis orientation for geographic coordinate systems.  I'm preparing an
RFC for WCS 1.1 that address this but in order to demonstrate the service
later this week I'd like to actually commit the relavent code.  The
changes will mean that msOWSCommonBoundingBox() will actually re-orient
the axes for the min/max values if the CRS is of the form
urn:ogc:def:crs:EPSG::4???.

I'm sending this email to warn you since I'm concerned this might affect
SOS which I assume is the only other code currently using
msOWSCommonBoundingBox().

Does SOS expect to report EPSG preferred axis order in stuff like bounding
boxes?  Does it use URN style coordinate system definitions or "EPSG:n" style?

BTW, the very brief summary of my axis handling efforts looks like this:

"""
URNs / Coordinate Systems and Axis Orientation
----------------------------------------------

WCS 1.1 uses URNs like "urn:ogc:def:crs:EPSG::4326" or
"urn:ogc:def:crs:OGC::CRS84".  In addition the WCS protocol is required to
honour EPSG axis conventions when using coordinate systems within the EPSG
authority space.  This means, for instance, that any coordinates in
the urn:ogc:def:crs:EPSG::4326 coordinate system must be provided in lat,long
ordering instead of the conventional long,lat.

In order to implement these requirements, several changes are planned:

- msLoadProjectionString() will be updated to expand URNs in the EPSG and OGC
name spaces.
- msLoadProjectionString() will add the "+epsgaxis=ne" parameter for URNs for
   GCS codes in the EPSG name space.
- New msAxisNormalizePoints() and msAxisDenormalizePoints() will be added for
   converting between normalized (easting,northing) axis orientation and
   EPSG preferred (denormalized) axis orientation (sometimes northing,easting).
   These functions will scan the p->args[] list for the +epsgaxis=ne to decide.
- msOWSCommonBoundingBox() will be modified to use these axis denormalization
   function to denormalize axis ordering for EPSG GCS URNs.
- the WCS 1.1 GetCoverage call will use msAxisNormalizePoints() to fix up
   orientation of request axes when needed.
"""

Best regards,
--
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up   | Frank Warmerdam, [hidden email]
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | President OSGeo, http://osgeo.org
Reply | Threaded
Open this post in threaded view
|

Re: Axis Orientation and msOWSCommonBoundingBox()

Kralidis,Tom [Ontario]
> Tom,
>
> As we have touched on in the past, for WCS 1.1 I need to
> honour EPSG axis orientation for geographic coordinate
> systems.  I'm preparing an RFC for WCS 1.1 that address this
> but in order to demonstrate the service later this week I'd
> like to actually commit the relavent code.  The changes will
> mean that msOWSCommonBoundingBox() will actually re-orient
> the axes for the min/max values if the CRS is of the form
> urn:ogc:def:crs:EPSG::4???.
>
> I'm sending this email to warn you since I'm concerned this
> might affect SOS which I assume is the only other code
> currently using msOWSCommonBoundingBox().
>

Currently, no other code (except for now mapwcs11.c) uses
msOWSCommonBoundingBox.  I had implemented it so that it would be there
ready as implementations of standards migrated to OWS Common.

SOS uses msGML3BoundedBy, because SOS 1.0.0 uses GML to specify bounding
boxes instead of OWS Common.

> Does SOS expect to report EPSG preferred axis order in stuff
> like bounding boxes?  Does it use URN style coordinate system
> definitions or "EPSG:n" style?
>

From what I see in the standard, EPSG:n is used for SOS GetCapabilities
responses, with axis order being "y x" (a la WFS).  We have, in
MapServer, coded EPSG:n, with "x y", for "practical interoperability".
Having said this, I have had one SOS client call out my
(MapServer-based) SOS expecting "y x".  This is for GetCapabilities
responses.

For GetObservation responses, SOS uses OM as the encoding.  OM uses URN
style defs.  Right now output "urn:ogc:crs:epsg:4326" type thing (with
"x y" order) as the def for GetObservation responses (where this should
be "y x").

In summary, we haven't delved to deeply into the axis ordering issues,
and have followed mostly WFS-ish behaviour.  I think we will have to
update this in SOS.

So I think the SOS support should move along with this RFC, especially
for SOS GetObservation responses.


> BTW, the very brief summary of my axis handling efforts looks
> like this:
>
> """
> URNs / Coordinate Systems and Axis Orientation
> ----------------------------------------------
>
> WCS 1.1 uses URNs like "urn:ogc:def:crs:EPSG::4326" or
> "urn:ogc:def:crs:OGC::CRS84".  In addition the WCS protocol
> is required to honour EPSG axis conventions when using
> coordinate systems within the EPSG authority space.  This
> means, for instance, that any coordinates in the
> urn:ogc:def:crs:EPSG::4326 coordinate system must be provided
> in lat,long ordering instead of the conventional long,lat.
>
> In order to implement these requirements, several changes are planned:
>
> - msLoadProjectionString() will be updated to expand URNs in
> the EPSG and OGC name spaces.
> - msLoadProjectionString() will add the "+epsgaxis=ne"
> parameter for URNs for
>    GCS codes in the EPSG name space.
> - New msAxisNormalizePoints() and msAxisDenormalizePoints()
> will be added for
>    converting between normalized (easting,northing) axis
> orientation and
>    EPSG preferred (denormalized) axis orientation (sometimes
> northing,easting).
>    These functions will scan the p->args[] list for the
> +epsgaxis=ne to decide.
> - msOWSCommonBoundingBox() will be modified to use these axis
> denormalization
>    function to denormalize axis ordering for EPSG GCS URNs.
> - the WCS 1.1 GetCoverage call will use
> msAxisNormalizePoints() to fix up
>    orientation of request axes when needed.
> """