Jody Garnett ha scritto:
> On 17/06/2010, at 5:37 PM, Andrea Aime wrote:
>
>> Jody Garnett ha scritto:
>>> DPI is an indication of pixels per inch; a ratio we can then go
>>> on to use to base line our configuration; when outputting
>>> results. To be explicit: - For a symbol size specified in pixels;
>>> I expect it to shrink to the point of stupidity when DPI is
>>> increased - For a symbol size specified in a UOM; I expect it to
>>> remain the same physical size when DPI is increased (the number
>>> of pixels it takes to accomplish will increase)
>> I kind of expected that as well, but it's not happening. You
>> increase the DPI and the width specified in km do not change.
>
> That sounds like a bug; are we using the unit of measure code to
> convert from km to pixels? Or do we perform our own conversion...
It's just using the map scale and dpi, basically eliminating the dpi
out of the final equation (since the map scale is dpi dependent too).
From UomRescaleStyleVisitor:
protected double computeRescaleMultiplier(double mapScale,
Unit<Length> uom) {
// no scaling to do if UOM is PIXEL (or null, which stands for
PIXEL as well)
if (uom == null || uom.equals(NonSI.PIXEL))
return 1;
// converts value from meters to given UOM
UnitConverter converter = uom.getConverterTo(SI.METER);
return converter.convert(mapScale);
}
However, I tried and if I do a separate DPI rescaling I get the expected
behavior both with pixel and m units. That's why I was proposing to go
that way (two separate rescalings, one just for dpi compensation, the
other just for uom).
>>> To be realistic: I kind of expect that we will need an option
>>> telling the renderer to accept Java2D default concept of 72
>>> pixels per inch when it sees a pixel; just to prevent the
>>> constant questions of why the output does not match the screen.
>> That's the same need I'm expressing. People want the printout to
>> look like the screen. I suggested to call it DPI setting, but it
>> seems people don't agree with that. How should I call it?
>
> Yeah it is a separate setting (used to provide a screen correction
> for mapping screen sizes to inches) so you can then go and apply the
> DPI of the final target device. That is starting to treat data pixels
> as a normal UOM like all the others with a conversation ratio to
> convert it into device pixels.
>
> Outline for rendering 300 dpi: - DPI gives us pixels per inch;
> allowing us to convert from any data UOM to output pixels - Font size
> converted from pt to 300 dpi (may need to go by way of Java2D 72dpi
> assumption) - data pixels (ie data provided with pixels as UOM)
> converted 1:1 to output pixels
>
> Outline for SCREEN_CORRECTION=72 at 300dpi (The setting of 72 dpi
> matching Java2D documentation) - DPI gives us pixels per inch;
> allowing us to convert from any data UOM to output pixels - Font
> sized in pt; Java 2D renders to strokes; and then strokes output at
> 300 dpi - data pixels (ie data provided with pixels as UOM) converted
> from 72:300 to output pixels
Mind OGC states a different default DPI, I think it's close to 90,
and that's what a compliant WMS must use (at the very least for
scale computations).
I'm still confused though. How would you call the WMS parameter
needed for the correction?
Anyways, it seems more and more that this should be done in the
WMS rather than in the renderer itself, so I guess I'll just
patch GeoServer and leave GeoTools unmodified.
>
> Got it - please do it as a separate "pixel correction" setting,
> rather then DPI. If possible get them to describe the size of a pixel
> in real world units; rather then in terms of dots.
That is problematic as they just know what the target printing dpi is.
I'm also asking the MapServer folks about what they do (e.g., if there
is a WMS parameter to do that, if they have, I'd prefer to just
align with theirs).
In the mapfile they basically specify two dpis:
MAP
...
RESOLUTION 300
DEFRESOLUTION 72
SIZE 1667 1667
...
END
See "usage example" at
http://mapserver.org/development/rfc/ms-rfc-55.html
Cheers
Andrea
--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.
------------------------------------------------------------------------------
ThinkGeek and WIRED's GeekDad team up for the Ultimate
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
lucky parental unit. See the prize list and enter to win:
http://p.sf.net/sfu/thinkgeek-promo
_______________________________________________
Geotools-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
