[Geoserver-devel] handling axis order in wms 1.3

GeoServer GeoServer Developer
1

Hi all,

I was hoping to get some advice on how to handle the axis ordering issue of wms 1.3. I have a partial approach that seems to work but i have no idea if it is a good one :). And a disclaimer that I have not throughly tested it.

So the first thing I did was update the wms kvp parsing so that the SRS (CRS in wms 1.3) parameter has the explicit EPSG namespace. So basically replacing “EPSG” → “urn:x-ogc:def.crs:EPSG”. Doing that however let to an exception in the WrappingProjectionHandler class that lives in the geotools render module.

Examining that code I found that it calculates the radius of the earth and assumes a longitude/latitude axis ordering. So I played around with a quick hack to basically first check the axis order of the rendering areas envelope crs, and calculate accordingly. And it seemed to work. By flipping the order of coordinates in the BBOX parameter the map rendered properly.

To do the axis order check i basically stole code from GML2EncodingUtils.axisOrder, and shifted it to the CRS class from referencing. And then basically updated WrappingProjectionHandler to use it. See the attached (rough) patch.

So I guess my primary question is whether or not this approach is a good one or not, and if not what a better alternative is.

Thanks!

-Justin

–
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

(attachments)

axisorder.patch (4.05 KB)

2

On Fri, Dec 3, 2010 at 9:36 PM, Justin Deoliveira <jdeolive@anonymised.com> wrote:

Hi all,
I was hoping to get some advice on how to handle the axis ordering issue of
wms 1.3. I have a partial approach that seems to work but i have no idea if
it is a good one :). And a disclaimer that I have not throughly tested it.
So the first thing I did was update the wms kvp parsing so that the SRS (CRS
in wms 1.3) parameter has the explicit EPSG namespace. So basically
replacing "EPSG" -> "urn:x-ogc:def.crs:EPSG". Doing that however let to an
exception in the WrappingProjectionHandler class that lives in the geotools
render module.
Examining that code I found that it calculates the radius of the earth and
assumes a longitude/latitude axis ordering. So I played around with a quick
hack to basically first check the axis order of the rendering areas envelope
crs, and calculate accordingly. And it seemed to work. By flipping the order
of coordinates in the BBOX parameter the map rendered properly.
To do the axis order check i basically stole code from
GML2EncodingUtils.axisOrder, and shifted it to the CRS class from
referencing. And then basically updated WrappingProjectionHandler to use it.
See the attached (rough) patch.

The patch works for me, I wanted to bring back the same method in CRS
for different reasons. Just one thing, it's missing a test case.

So I guess my primary question is whether or not this approach is a good one
or not, and if not what a better alternative is.

Eh, there is another way, but you're not going to like it.
The GeoTools referencing system has been built under the assumption that
you want EPSG default axis order and that you'll explicitly ask if you need
otherwise. So if you let it be you have a way to get a CRS in lat/lon order, or
you use CRS.decode(srs, true) and get it in lon/lat instead.
However GeoServer forces the axis to lon/lat on startup and there is no
method to get them otherwise past using urn.

In theory we _could_ stop forcing the lon/lat order on startup and be explicity
in all our decode requests... but I fear that would open a massive can of
works and we'd be flooded :-p

So unless someone wants to go down with that undertaking let's
move on with your patch.

Cheers
Andrea

-----------------------------------------------------
Ing. Andrea Aime
Senior Software Engineer

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584962313
fax: +39 0584962313

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf

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

3

On Sat, Dec 4, 2010 at 1:04 AM, Andrea Aime <andrea.aime@anonymised.com> wrote:

On Fri, Dec 3, 2010 at 9:36 PM, Justin Deoliveira <jdeolive@anonymised.com> wrote:

Hi all,
I was hoping to get some advice on how to handle the axis ordering issue of
wms 1.3. I have a partial approach that seems to work but i have no idea if
it is a good one :). And a disclaimer that I have not throughly tested it.
So the first thing I did was update the wms kvp parsing so that the SRS (CRS
in wms 1.3) parameter has the explicit EPSG namespace. So basically
replacing “EPSG” → “urn:x-ogc:def.crs:EPSG”. Doing that however let to an
exception in the WrappingProjectionHandler class that lives in the geotools
render module.
Examining that code I found that it calculates the radius of the earth and
assumes a longitude/latitude axis ordering. So I played around with a quick
hack to basically first check the axis order of the rendering areas envelope
crs, and calculate accordingly. And it seemed to work. By flipping the order
of coordinates in the BBOX parameter the map rendered properly.
To do the axis order check i basically stole code from
GML2EncodingUtils.axisOrder, and shifted it to the CRS class from
referencing. And then basically updated WrappingProjectionHandler to use it.
See the attached (rough) patch.

The patch works for me, I wanted to bring back the same method in CRS
for different reasons. Just one thing, it’s missing a test case.

Cool. I will whip up a test case for the final patch and post it in geotools jira.

So I guess my primary question is whether or not this approach is a good one
or not, and if not what a better alternative is.

Eh, there is another way, but you’re not going to like it.
The GeoTools referencing system has been built under the assumption that
you want EPSG default axis order and that you’ll explicitly ask if you need
otherwise. So if you let it be you have a way to get a CRS in lat/lon order, or
you use CRS.decode(srs, true) and get it in lon/lat instead.
However GeoServer forces the axis to lon/lat on startup and there is no
method to get them otherwise past using urn.

In theory we could stop forcing the lon/lat order on startup and be explicity
in all our decode requests… but I fear that would open a massive can of
works and we’d be flooded :-p

So unless someone wants to go down with that undertaking let’s
move on with your patch.

Agreed. Sounds like quite an undertaking.

Cheers
Andrea

Ing. Andrea Aime
Senior Software Engineer

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584962313
fax: +39 0584962313

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf

–
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.