Here is a pull request: https://github.com/geotools/geotools/pull/527
Review very much welcomed, I'm supposedly in vacation today and looking after my children, and might not have time to look into this deeper for a good week Cheers Andrea On Fri, Aug 15, 2014 at 3:47 PM, Andrea Aime <[email protected]> wrote: > Hi, > sorry for the cross post, but we're close to RC1 and a user just reported > an issue of some gravity. > > The current OGC scale computation code is: > > public static double calculateOGCScale(ReferencedEnvelope envelope, int > imageWidth, Map hints) { > // if it's geodetic, we're dealing with lat/lon unit measures > if(envelope.getCoordinateReferenceSystem() instanceof > GeographicCRS) { > return (envelope.getWidth() * OGC_DEGREE_TO_METERS) / > (imageWidth / getDpi(hints) * 0.0254); > } else { > return envelope.getWidth() / (imageWidth / getDpi(hints) * > 0.0254); > } > } > > Now, the geographic crs case is using a fixed conversion ratio that is > given by OGC, > and that ends up dividing: > (envelope.getWidth() * OGC_DEGREE_TO_METERS) -> meters > with: > imageWidth / getDpi(hints) * 0.0254 -> meters > > However, in the case of projected CRS, we end up with: > envelope.getWidth() -> meters, feet, whatever the unit of measure of the > rendering is > over > (imageWidth / getDpi(hints) * 0.0254) -> meters > > Which means, when computing the scale on projected CRS using anything but > meters, > we get a wrong value (e.g., if it's feet, 3 times off...) > > Now, the fix is somehow obvious (we just ask Unit to provide the > conversion factor), > but the consequences are not: every SLD and every scale dependent code in > general > will end up being affected, and quite a bit so, but this fix. > > I propose that we add a system variable to control the unit conversion, > and > leave it on by default on trunk (that is, in RC1 too), and leave it > dormant on > the stable series. People will still be able to switch it on and off > manually > using the system variable, e.g. > -Dorg.geotoools.render.lite.scale.unitCompensation=true > > What do you think? > > Cheers > Andrea > > -- > == > GeoServer Professional Services from the experts! Visit > http://goo.gl/NWWaa2 for more information. > == > > Ing. Andrea Aime > @geowolf > Technical Lead > > GeoSolutions S.A.S. > Via Poggio alle Viti 1187 > 55054 Massarosa (LU) > Italy > phone: +39 0584 962313 > fax: +39 0584 1660272 > mob: +39 339 8844549 > > http://www.geo-solutions.it > http://twitter.com/geosolutions_it > > ------------------------------------------------------- > -- == GeoServer Professional Services from the experts! Visit http://goo.gl/NWWaa2 for more information. == Ing. Andrea Aime @geowolf Technical Lead GeoSolutions S.A.S. Via Poggio alle Viti 1187 55054 Massarosa (LU) Italy phone: +39 0584 962313 fax: +39 0584 1660272 mob: +39 339 8844549 http://www.geo-solutions.it http://twitter.com/geosolutions_it -------------------------------------------------------
------------------------------------------------------------------------------
_______________________________________________ GeoTools-Devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
