On Fri, Dec 3, 2010 at 9:36 PM, Justin Deoliveira <[email protected]> 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 ----------------------------------------------------- ------------------------------------------------------------------------------ What happens now with your Lotus Notes apps - do you make another costly upgrade, or settle for being marooned without product support? Time to move off Lotus Notes and onto the cloud with Force.com, apps are easier to build, use, and manage than apps on traditional platforms. Sign up for the Lotus Notes Migration Kit to learn more. http://p.sf.net/sfu/salesforce-d2d _______________________________________________ Geoserver-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geoserver-devel
