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

[Michael Barton]

David,

This is pretty much what is happening in gis.m currently. The rub is that
there needs to be independent region geometry ("window") for each open
display ("extent"), or all displays would show the same region. We're
handling that pretty well in gis.m currently, but some of raster and other
commands ignore this and check the single WIND file for the entire mapset.

Michael
__________________________________________
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: David Finlayson <david.p.finlayson at gmail.com>
> Date: Fri, 19 May 2006 09:53:53 -0700
> To: Michael Barton <michael.barton at asu.edu>
> Cc: <grass-dev at grass.itc.it>
> Subject: Re: [GRASS-dev] Re: grass-dev Digest, Vol 1, Issue 2297
> 
> It has been a while since I used command line ArcInfo, but it seemed
> to handle the distinction between the display window (called a map
> extent in Arc) and the region (called the "window") fairly well. There
> was a command for each: mapextent and setwindow respectively.
> 
> One of the features of setwindow command was an option to make the
> window exactly equal to the map extent, and vis-a-vis. That way if
> things got out of alignment, it was easy to align them back up. Once
> you got used to the idea, the distinction between the analysis window
> and the map extent was convenient.
> 
> One trick in the GUI to indicate the difference between the "map
> extent" (display canvas) and the "window" (region) would be to have a
> command that draws the region onto the display (an automatic version
> of v.in.region). When the region was larger than the display, use a
> dashed frame around the display.
> 
> ??
> 
> David
> 
> On 5/19/06, Michael Barton <michael.barton at asu.edu> wrote:
>> 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
>>> 
>> 
>> _______________________________________________
>> grass-dev mailing list
>> grass-dev at grass.itc.it
>> http://grass.itc.it/mailman/listinfo/grass-dev
>> 
> 
> 
> -- 
> David Finlayson