[GRASS5] d.info: flag added for approximate screen scale
Markus Neteler
neteler at itc.it
Thu Jan 5 10:54:53 EST 2006
On Thu, Jan 05, 2006 at 03:19:55PM +0000, Glynn Clements wrote:
>
> Markus Neteler wrote:
>
> > I have added a new flag to d.info to print the
> > approximate map scale in GRASS monitor. I know that
> > it's not very precise, but an approximate figure
> > is better than nothing:
> >
> > Example:
> >
> > d.info -s
> > Approximate map scale in GRASS monitor <x0> 1:11000
> >
> > I remember that this was removed in GRASS 5 (not by me)
>
> It was removed for a reason, namely that it relied upon a whole bunch
> of assumptions (e.g. you have X libraries installed, you are using X,
> the monitor being queried is XDRIVER, you know which X display the
> monitor is using, etc) which aren't guaranteed to be true.
As suggested: It could be made optional.
> > but IMHO a GIS should be able to give such information.
>
> The driver protocol doesn't include the necessary support.
This is not clear to me. If I
- have the map extent in pixel
- have the dots per pixel of the monitor (ok, an approximation)
why cannot an *approximate* scale be given? How to all the
other GIS solve it?
> The feature relied upon assuming that you can find X display, querying
> the resolution of that display, and assuming that display is the one
> which the monitor is using.
The algorithm gives the name of the monitor. I agree that this
won't work if the monitor is shown on a different machine.
But I am sure that this could be tested as well beforehand.
> > The algorithm takes the monitor size, the map size within
> > the monitor and the screen resolution (x DPI and y DPI)
> > into account. The latter may not be precise, depending on
> > the X server software, video card or monitor. The
> > figure is therefore given rounded.
> >
> > It still needs to be make optional in the Makefile
> > in case of X absences. Hints for a test are welcome.
>
> The configure script only determines which libraries are available. It
> cannot determine whether or not you want to use them. In the case of
> the d.info hack, it's entirely possible that you won't want it even if
> the X libraries are available on the build system (e.g. because you
> want to build a package for distribution, and don't want to include a
> version of d.info which simply won't run on systems without Xlib).
What about XDRIVER then?
neteler 3672 1 0 12:52 pts/6 00:00:03 /hardmnt/bartok0/ssi/software/cvsgrass61/dist.x86_64-unk
nown-linux-gnu/driver/XDRIVER x0 dev/fifo.1a dev/fifo.1b
/usr/sbin/lsof -p 3672 | grep libX11
XDRIVER 3672 neteler mem REG 9,0 922040 755424 /usr/X11R6/lib64/libX11.so.6.2
It's at least a similar case. I don't see in the Makefile that it
is optional (maybe I am wrong).
> > I hope the flag survives this time :-)
>
> Not if I have anything to do with it.
OK, I can always extract it to a private module.
> The reasons for its removal remain valid. Primarily, the fact that it
> caused the d.info executable to have an Xlib dependency.
I have conditionalized upon X11 presence now.
Only the Makefile test fails surprisingly.
> The other
> problems don't matter so long as you don't use the -s switch.
Right. And there are a couple of other problems in GRASS which
I would like to see to be taken out - but I simply don't use
them.
Markus
More information about the grass-dev
mailing list