[GRASS-dev] Scale display in GRASS Monitor

[Markus Neteler]

On Thu, Sep 21, 2006 at 06:18:23PM +0100, Glynn Clements wrote:
> 
> Markus Neteler wrote:
> 
> > >> the GRASS monitor does not show the approx. scale of the map.
> > >> In the past I introduced that one or two times but it was
> > >> reverted. Since every GIS shows a scale on screen, it is
> > >> hard to explain why GRASS doesn't do it.
> > >>
> > >> So I launch a new attempt to get the scale (back) on top
> > >> of the GRASS monitor... I know about dpi and all this stuff
> > >> but we really don't need centimeter precision :-)
> > >>
> > >> Opinions?
> > >
> > > The movement towards gis.m and the PNG driver only makes this even
> > > less feasible now than it was in the past. What is the DPI of a
> > > PNG/PPM file?
> > >   
> > I was thinking of the XDRIVER GRASS monitor only.
> > > I'm willing to extend the driver protocol so that such a feature
> > > becomes possible, if you can:
> > >
> > > 1. Persuade me that even at this late stage in its life, XDRIVER is
> > > still worth extending.
> > >   
> > I have the code ready...
> > > 2. Convince me that it really doesn't matter that the reported scale
> > > will be *significantly* inaccurate for most users.
> > >
> > > [For me, xdpyinfo reports 75x75dpi. Given that the screen resolution
> > > is 1920x1440, that implies that I have a 32" monitor. In reality, the
> > > monitor is (nominally) 22", so the actual resolution is more like
> > > 110dpi. IOW, the reported resolution has a relative error of ~50%.]
> > >   
> > I have tested it on my monitor (flat screen):
> > 
> > d.screenscale
> >   D0/0: True map size:  we_meters: 19020.000000 ns_meters: 14310.000000
> >   D0/0: monitor size: screen_we_pix: 640 screen_ns_pix: 480
> >   D0/0: Pixel numbers used in screen: ns: 480.000000  we:637.000000
> >   D0/0: Map rows: 477  map cols: 634
> >   D0/0: Xserver screen resolution: x:85.109948 dpi y:83.097764 dpi
> 
> Your X server is configured with knowledge of the physical screen
> dimensions of your monitor (either through manual configuration or via
> DDC).

It should be DDC based (automatically).
 
> That won't be true for all X servers. Apart from anything else,
> anything other than 75x75 or 100x100 dpi tends to produce ugly (even
> illegible) results with legacy applications and bitmap font. 
> Conseqently, many users (including myself) lie about the monitor
> dimensions to force the computed resolution to equal 75x75dpi.
> 
> It doesn't work with Cygwin's XWin.exe (which doesn't have a
> configuration file; and in any case, Windows only gives you a choice
> of 96 or 120dpi, and quite a few applications are hardcoded to 96dpi).

ok

> There are plenty of other cases where trying to report accurate
> physical dimensions will fail: multiple, different-sized monitors in
> clone mode (typically used if you have a laptop which is sometimes
> connected to an external monitor), dynamic resolution changes via
> RandR, etc.
> 
> >   D0/0:  Map height in true centimeter on screen: 14.325000
> >   D0/0:  Map width in true centimeter on screen:  19.470801
> >   D0/0:  (note: deviations may arise from your screen adjustments)
> >   D0/0:  Current map scale (note: Xserver x_res != y_res):
> >   D0/0:    y-scale: 1:99895.287958
> >   D0/0:    x-scale: 1:97684.734253
> >   Approximate map scale in GRASS monitor <x0> 1:99000
> > 
> > Compared to the measured monitor window dimensions, they deviate for me by
> > around 3% in x direction and 1% in y direction which IMHO is fair.
> > > 3. Tell me what resolution the PNG driver should report.
> > >   
> > Maybe none? Or is the XDRIVER now a  wrapper around the PNG driver? I lost
> > a bit track how it is working now.
> 
> The only reliable way for a client to obtain the display resolution is
> to ask the driver for this information (querying the resolution of
> some random X server which may or may not be the one on which XDRIVER
> is running is no better than hardcoding 75x75dpi; or using rand(), for
> that matter).

I don't know if this is really close to rand(). Scale display could be
contitionalized to local connections.

> For the driver to provide this information, there needs to be an R_*
> function (and a corresponding protocol opcode). In turn, this means
> that each driver must implement this operation. It's easy enough to do
> for XDRIVER (although I suspect that libW11 will need to be extended
> or else --enable-w11 will stop working), but what should the PNG
> driver implementation do?

Given all these problems, I wonder how
- qgis
- udig
- ESRI
- Mapserver
- ...

are displaying the scale? All fooling the user? GRASS is probably the
only GIS in the world not displaying a scale (how does d.barscale work?).

Markus