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

[Michael Barton]

I was half asleep when I responded (keeping my son company why he studied
for finals). Here are a couple clarifications.
__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics and Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton


> From: <grass-dev-request at grass.itc.it>
> Reply-To: <grass-dev at grass.itc.it>
> Date: Fri, 19 May 2006 12:12:23 +0200
> To: <grass-dev at grass.itc.it>
> Subject: grass-dev Digest, Vol 1, Issue 2297
> 
>> 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.

> 
>> 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.

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.

> 
>> 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.


Michael
>