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
