[GRASS-dev] Re: grass-dev Digest, Vol 1, Issue 2297

[Glynn Clements]

Michael Barton wrote:

> >> The only other thing I can think of that really needs to be fixed (can be
> >> dealt with as a bug fix after the freeze) is the region problem. Maybe it's
> >> already fixed by Cedric, but I haven't had a chance to check it yet.
> > 
> > Region problem? Is that a gis.m problem, or elsewhere?
> 
> It is a mixed problem, having to do with the way some modules interact with
> the WIND file (currently under discussion) and the need to have multiple
> region settings in gis.m. In recent versions of gis.m, if the WIND file gets
> set to a small region, you use gis.m to zoom out to a larger region, and you
> try to query a raster file (using r.what), you can get a response that the
> query is outside the map extents. I think that his cropped up when Cedric
> changed from the messier multiple saved regions that I had been using to
> create independent regions for each display to a cleaner internal variable
> system. There may be a workaround already in place (I'm not sure), but it is
> related to the discussion about how to deal with the single WIND file when
> you may need multiple region settings for a variety of reasons.

gis.m should use either WIND_OVERRIDE or GRASS_REGION and ignore the
WIND file (other than to provide an option to "import" it).

> >> Doing replacements for i.points and v.digit will take more work, possibly
> >> reprogramming in C (pretty sure about v.digit, still might be able to do all
> >> of an i.points replacement in TclTk, but I'm not yet sure).
> > 
> > i.points should be doable in Tcl/Tk, although you might want to
> > salvage the mathematical code from i.points and keep that in a C
> > helper module rather than re-writing it in Tcl/Tk. Apart from anything
> > else, it may be useful for non-interactive use.
> 
> One thing that would make this considerably easier to carry off is being
> able to import an xy map into a georeferenced location. Having to switch
> locations (from georeferenced to xy and back for every change in window and
> region geometry) AND track the temporary display files is complicated and I
> worry that it might cause problems. Being able to georeference a file
> without switching locations would make life much easier.

In terms of "switching" regions, I would maintain a completely
separate $GISRC file for the X-Y location and change env(GISRC) rather
than switching a single $GISRC file between locations.

In any case, I'm not sure that it's appropriate to import maps into a
location with the wrong projection.

> However, import modules (r.in.gdal at least) won't let you import an xy map
> into any location (e.g., latlon) where the map extents exceed the legal
> maximum values of the referencing system. That is, you can't import a map
> with xy extents of 0-1000x and 0-1000y into a latlon location where latitude
> only goes to 90 and longitude goes to 180. IMHO, it would be better if it
> just gave you a warning and then let you go ahead if you wanted to do so.

It would be simple to change G_adjust_Cell_head() to generate a
warning then indicate success in this case.

But that only really matters for importing lat-lon maps into a lat-lon
location. Maps with no defined projection should be imported into an
X-Y location then rectified from there.

> >> As much as I'd
> >> like to have a complete x11 free GUI for 6.2, I don't think we can get there
> >> yet--unless some rapidfire development can be done by someone else. But
> >> we've come a long way and have a very nice product.
> > 
> > AFAICT, the main obstacles are v.digit and NVIZ. v.digit needs a
> > decision on a suitable toolkit (probably either Qt or wxWidgets) and a
> > volunteer. NVIZ requires someone to update Togl to 1.7 and to
> > conditionalise the GLX-specific code in do_zoom.c.
> 
> For someone who doesn't know anything about the relevant coding, this seems
> like a fairly easy fix for NVIZ.

I initially suspected that most of it would be down to figuring out
how GRASS' copy of Togl has deviated from the original and merging any
necessary fixes into 1.7. AFAICT, the changes are all just adding new
versions of tkInt*.h, plus one change which replaced calloc/free with
G_calloc/G_free (which isn't really necessary).

However, NVIZ compiles fine with Togl 1.7, but segfaults on startup
due to Ndraw_all trying to read certain Tcl variables before they've
actually been created. I'm not sure why Ndraw_all is being called
earlier with the new version of Togl, and I can't easily find out
until I've had chance to rebuild my Tcl/Tk libraries with debug info.

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