[GRASS-dev] gis.m improvements

[Glynn Clements]

Michael Barton wrote:

> > 3. NVIZ respects my system settings for menu colors. I think so should
> > the GUI module forms and gis.m. It just integrates much better
> > with the rest of the user desktop.
> 
> I'm not so sure about this, though I understand your point. I'm not sure how
> easy it is to lift the menu colors on all platforms. We'd need to see how it
> looks if you do this. It might not work right. Most of this is now set in
> the options database. Perhaps the better thing would be have a little gui
> app that would allow you to set it to whatever you want.

By default, the GUI shouldn't specify colours for most widgets. Tk
should be able to figure out the system defaults by itself.

> > 4. querying raster maps from a Map Display is buggy: if my working
> > region is set smaller than the raster's total extent and I
> > user "Zoom to selected map", querying will return NULL values "*",
> > for all parts of the displayed map outside the working region.
> 
> I've been looking at this and here is what happens. By design, gis.m does
> not mess with the WIND file. You can only change WIND via g.region. By
> design, the displays do not read the WIND file unless you explicitly
> instruct a display to do so (zoom to current region). This is so that each
> display can have an independent region setting (extengs, resolution). So far
> so good.
> 
> But r.what reads the WIND file.

Everything which accesses raster maps will crop and resample them
according to the current region, which is whatever is in the WIND file
unless you set WIND_OVERRIDE to specify a saved region.

> If its coordinate input is outside the
> extents listed in the file, it gives an error. V.what does NOT worry about
> the WIND file and will query any coordinates you give it.
> 
> It seems that r.what needs to be modified so as to not worry about the
> extents in the WIND file. I don't see an easy work around for this (beyond
> setting the region with g.region). We really don't want to have the map
> displays mess with the WIND file.

I added WIND_OVERRIDE to deal with this specific issue. There is no
need to make specific modifications to any modules.

gis.m should be setting WIND_OVERRIDE for any command which
corresponds to a specific display, not just r.what.

-- 
Glynn Clements <glynn at gclements.plus.com>