Hi,
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?
Markus
hallo,
On Wed, Sep 20, 2006 at 06:37:06PM +0200, Markus Neteler wrote:
Hi,
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 precisionOpinions?
Markus
imho good idea. I vote for bottom-right corner
jachym
--
Jachym Cepicky
e-mail: jachym.cepicky@centrum.cz
URL: http://les-ejk.cz
GPG: http://les-ejk.cz/gnupg_public_key/jachym_cepicky-gpg_public_key.asc
-----------------------------------------
OFFICE:
GDF-Hannover
Mengendamm 16d
30177 Hannover
Germany
e-mail: cepicky@gdf-hannover.de
URL: http://gdf-hannover.de
Tel.: +49 511-39088507
Hi,
maybe a wrong idea, should be this feature part of d.barscale module?
I wanted to rewrite this module some time ago, I would have new
motivation to do it now...
Best, Martin
2006/9/20, Markus Neteler <neteler@itc.it>:
Hi,
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 precisionOpinions?
Markus_______________________________________________
grass-dev mailing list
grass-dev@grass.itc.it
http://grass.itc.it/mailman/listinfo/grass-dev
--
Martin Landa <landa.martin@gmail.com> * http://gama.fsv.cvut.cz/~landa *
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 precisionOpinions?
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'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.
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%.]
3. Tell me what resolution the PNG driver should report.
--
Glynn Clements <glynn@gclements.plus.com>
Glynn Clements wrote:
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%.]
For me the error is "only" 25%. Given that, I doubt adding such a
feature would make much sense. It could trigger frustration, false bug
reports and hamper Grass's PR.
Maciek
Glynn Clements wrote on 09/20/2006 09:59 PM:
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 precisionOpinions?
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
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.
Markus
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).
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).
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:99000Compared 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).
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?
--
Glynn Clements <glynn@gclements.plus.com>
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 dpiYour 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
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?).
I didn't follow the whole discussion, so I hope I'm answering to what
was asked...
I can only tell about JGrass. We have a scalebar and yes, if you want to
see it like that, somehow we are fooling the user, even if of a very small
amount (I never needed it precise on the monitor). Since we retrieve the
resolution from the drivers, We are exposed to the problems listed above.
But I don't really mind about measuring the screen with a ruler, the important
to me is to get the proper result when I print the map.
And on paper the scale I see on the screen is returned to me with a millimetric
precision which that is what I need.
Regards,
Andrea
Markus Neteler wrote:
> 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.
You don't know whether the monitor is using a local connection.
Actually, the monitor might not even know; if you use ssh's X
forwarding, the connection appears to be location (sshd creates a
local proxy, so the connection will appear local).
> 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?
Most likely. IOW, I suspect that the scale is based upon the
"reported" display resolution (e.g. 96dpi for Windows) rather than on
reality.
GRASS is probably the only GIS in the world not displaying a scale
(how does d.barscale work?).
d.barscale doesn't need to know anything about the resolution of the
display. It only needs to know the conversion between metres and
pixels, the same as every other map display module.
--
Glynn Clements <glynn@gclements.plus.com>
Antonello Andrea wrote:
> 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?).I didn't follow the whole discussion, so I hope I'm answering to what
was asked...I can only tell about JGrass. We have a scalebar and yes, if you want to
see it like that, somehow we are fooling the user, even if of a very small
amount (I never needed it precise on the monitor). Since we retrieve the
resolution from the drivers, We are exposed to the problems listed above.But I don't really mind about measuring the screen with a ruler, the important
to me is to get the proper result when I print the map.
And on paper the scale I see on the screen is returned to me with a millimetric
precision which that is what I need.
For printing, determine the scale factor is straightforward, as
PostScript works in physical units. Of course, that fails if someone
rescales the PostScript file afterwards, or makes a photocopy at 70%,
etc.
It's a lot more robust to just use a scale bar like d.barscale.
--
Glynn Clements <glynn@gclements.plus.com>
On Fri, Sep 22, 2006 at 05:24:47PM +0100, Glynn Clements wrote:
...
It's a lot more robust to just use a scale bar like d.barscale.
Could the method of d.barscale somehow be used?
But I still don't believe that people use 50dpi monitors...
Well, I guess I should shut up now. My potential submissions
would be reverted anyway.
Markus
Markus Neteler wrote:
> It's a lot more robust to just use a scale bar like d.barscale.
Could the method of d.barscale somehow be used?
What method?
d.barscale just draws a bar with a given length in map coordinates. It
neither knows nor cares how large the bar will be (physically) on the
monitor.
d.barscale only needs to be able to transform map coordinates to
pixels, which we do whenever we draw a map. It's converting pixels to
physical dimensions which is problematic.
--
Glynn Clements <glynn@gclements.plus.com>
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 precisionOpinions?
why not a checkbox in the GUI which will overlay:
d.barscale -l at=0,0
? [easy]
or do you want "1:50000" in the window title. [hard]
For reasons outlined by Glynn, I am against adding "1:50000" which
would be a guess and will often be wrong. Let's not introduce known
mistakes. GpsDrive was written using such a thing and it is a horrible
hack (I worked the "magic" constant backwards, and figured the original
calculation was done on a 17" 800x600 monitor, and has been "wrong"
ever since monitors improved from those).
Also this doesn't work for lat/lon locations.
Another point worth mentioning: "ps.map scale=" (1:50000) is badly
broken for lat/lon scales, as has been for a long time.
http://intevation.de/rt/webrt?serial_num=3096
I know Arc lets you put bogus scale bars on lat/lon maps (customers
"asked for it"..), but IMO this borders on legal liability for the
resultant fuc ups.
Martin:
maybe a wrong idea, should be this feature part of d.barscale module?
I wanted to rewrite this module some time ago, I would have new
motivation to do it now...
why? what do you find wrong with it?
Hamish
How about having a global conversion factor that can be calibrated,
e.g. as an environment variable.
Give the user the option to manually calibrate that: show him a bar or
set of bars, ask him to measure it/them using a ruler and report the
results. That would be neat at graphical startup screens. We can even
have our own (reliable) measures to test against absurd values.
Just an idea. It's rather odd that no GIS implements this kind of
artisanal method...
Daniel.
On 9/23/06, Glynn Clements <glynn@gclements.plus.com> wrote:
Markus Neteler wrote:
> > It's a lot more robust to just use a scale bar like d.barscale.
>
> Could the method of d.barscale somehow be used?What method?
d.barscale just draws a bar with a given length in map coordinates. It
neither knows nor cares how large the bar will be (physically) on the
monitor.d.barscale only needs to be able to transform map coordinates to
pixels, which we do whenever we draw a map. It's converting pixels to
physical dimensions which is problematic.--
Glynn Clements <glynn@gclements.plus.com>_______________________________________________
grass-dev mailing list
grass-dev@grass.itc.it
http://grass.itc.it/mailman/listinfo/grass-dev
--
-- Daniel Calvelo Aros
Daniel Calvelo wrote:
How about having a global conversion factor that can be calibrated,
e.g. as an environment variable.Give the user the option to manually calibrate that: show him a bar or
set of bars, ask him to measure it/them using a ruler and report the
results. That would be neat at graphical startup screens. We can even
have our own (reliable) measures to test against absurd values.Just an idea. It's rather odd that no GIS implements this kind of
artisanal method...
the Gimp used to let you do this when you installed it, ie displayed a
ruler on the screen and asked you to measure it. AFAICT in the Gnome
"dumming down" efforts this has been abandoned, or at least isn't
presented as part of the new install wizard.
I'm afraid I don't see the benefit, but do see a lot of problems.
Hamish
Hamish wrote:
> How about having a global conversion factor that can be calibrated,
> e.g. as an environment variable.
>
> Give the user the option to manually calibrate that: show him a bar or
> set of bars, ask him to measure it/them using a ruler and report the
> results. That would be neat at graphical startup screens. We can even
> have our own (reliable) measures to test against absurd values.
>
> Just an idea. It's rather odd that no GIS implements this kind of
> artisanal method...the Gimp used to let you do this when you installed it, ie displayed a
ruler on the screen and asked you to measure it. AFAICT in the Gnome
"dumming down" efforts this has been abandoned, or at least isn't
presented as part of the new install wizard.I'm afraid I don't see the benefit, but do see a lot of problems.
The main problem being that the user will probably forget to update
the information if they change the size of the desktop or switch
monitors.
But that's a minor issue. If we force the user to specify the
resolution, all of our problems go away (there are still problems, but
they're not *our* problems).
I can see the point in having a scale printed on paper maps where
people actually measure distances on the map using dividers and a
ruler. I doubt that people do this with a monitor (dividers probably
aren't particularly kind to the surface of the monitor, and d.measure
is likely to be easier to use).
--
Glynn Clements <glynn@gclements.plus.com>
On Thu, Sep 28, 2006 at 04:18:07PM +0100, Glynn Clements wrote:
...
I can see the point in having a scale printed on paper maps where
people actually measure distances on the map using dividers and a
ruler. I doubt that people do this with a monitor (dividers probably
aren't particularly kind to the surface of the monitor, and d.measure
is likely to be easier to use).
I am still convinced that a map scale is an essential ingredient of
a map. Since there are much less paper maps nowadays, geographers
like me (certainly also non-geographers) expect to see a scale
also in a GIS.
If you look at data of an area which you don't know, a map scale
is a great help to better understand the visual representation.
I also doubt that people start to measure on screen but this was
not asked at all. It is a great help to immediately understand if you
zoomed to 1:10000 or 1:1mio (since d.zoom doesn't tell anything about the
current scale). Especially with vector data, the map scale is often
not obvious (while it is much easier to grasp with (shaded) DEM).
The idea of using a d.barscale activation switch in gis.m does not
solve the problem for us command line junkies.
Markus
Markus Neteler wrote:
On Thu, Sep 28, 2006 at 04:18:07PM +0100, Glynn Clements wrote:
...I can see the point in having a scale printed on paper maps where
people actually measure distances on the map using dividers and a
ruler. I doubt that people do this with a monitor (dividers probably
aren't particularly kind to the surface of the monitor, and d.measure
is likely to be easier to use).I am still convinced that a map scale is an essential ingredient of
a map. Since there are much less paper maps nowadays, geographers
like me (certainly also non-geographers) expect to see a scale
also in a GIS.If you look at data of an area which you don't know, a map scale
is a great help to better understand the visual representation.
I also doubt that people start to measure on screen but this was
not asked at all. It is a great help to immediately understand if you
zoomed to 1:10000 or 1:1mio (since d.zoom doesn't tell anything about the
current scale). Especially with vector data, the map scale is often
not obvious (while it is much easier to grasp with (shaded) DEM).
But this could be provided in form of a barscale, not a numeric scale, or ?
The idea of using a d.barscale activation switch in gis.m does not
solve the problem for us command line junkies.
If you're at the command line anyway, what's so difficult in typing d.barscale -s ?
Moritz
On Thu, Sep 28, 2006 at 05:49:55PM +0200, Moritz Lennert wrote:
...
If you're at the command line anyway, what's so difficult in typing
d.barscale -s ?
That's not difficult. But it hides a piece of the map.
A number somewhere else doesn't...
Markus