On Sat, Dec 4, 2010 at 1:04 AM, Andrea Aime <[email protected]>wrote:
> 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.
>
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.
------------------------------------------------------------------------------
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
