+1 too - that does explain his issue. Ian
On 15 August 2014 15:24, Jody Garnett <[email protected]> wrote: > Good call +1 (is this the same confusion reported on the user list?) > > Jody Garnett > > > On Fri, Aug 15, 2014 at 6:47 AM, 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 >> >> ------------------------------------------------------- >> >> >> ------------------------------------------------------------------------------ >> >> _______________________________________________ >> GeoTools-Devel mailing list >> [email protected] >> https://lists.sourceforge.net/lists/listinfo/geotools-devel >> >> > > > ------------------------------------------------------------------------------ > > _______________________________________________ > GeoTools-Devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/geotools-devel > > -- Ian Turton
------------------------------------------------------------------------------
_______________________________________________ GeoTools-Devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
