No subject

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