[GRASS-dev] Re: [GRASS GIS] #668: export and share region settings

[Michael Barton]

On Jul 5, 2009, at 2:52 AM, grass-dev-request at lists.osgeo.org wrote:

> Date: Sat, 04 Jul 2009 23:28:46 +0200
> From: Tim Michelsen <timmichelsen at gmx-topmail.de>
> Subject: [GRASS-dev] Re: [GRASS GIS] #668: export and share region
>        settings
> To: grass-dev at lists.osgeo.org
> Cc: grass-user at lists.osgeo.org
> Message-ID: <h2ohie$4iu$3 at ger.gmane.org>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
>> I don't understand what you want to do here.
> Image the following use case:
> You have project location.
> Then you would like to test out some new processing workflows or
> developed a new methodology.
> In order not to pollute the project location with a lot of test  
> rasters,
> you start a new location to do the testing.
>
> It would be nice to have the save region settings available for /all/
> locations with the same projection.
>
>> If you are trying to use a region defined in one location within  
>> another
>> location, you can do that--at your own risk. Just copy the region def
>> file from location1/mapset1 to location2/mapset2.
> What is wrong with making the files in
> location1/PERMANENT/windows
> available to all locations with the same project in the GRASS  
> database?
>
> The region settings do not contain projection information.
> This may be changed in GRASS 7. Then, the GUI could show a list of
> region settings with the same projection when zooming to a saveed  
> region
> setting.
>
> There may be many users (regional government offices, unis with  
> studies
> in their neighborhood) how may also want this kind of sharing feature.
> This could increase usability of the map display in the GUI.
>
> The work the coders of the wxGUI did was a tremendous step towards  
> this
> direction!
>
>> care. I know it can be annoying sometimes for people coming from  
>> other
>> GIS programs, but GRASS has long had a philosophy of emphasizing the
>> importance of accurate digital mapping and cartography--something  
>> that
>> is probably tied to its primarily scientific, rather than commercial,
>> development and use.
> Commercial users do also need the best accuracies.
> But they seem to have also a high focus on the usability and  
> effectivity
> of use when performing all day tasks.
> And I cannot imagine that academia can affort wasting time in
> long-winded workflows.
>
>> The location/mapset structure is an important
>> aspect of maintaining that accuracy.
> Please let's not start flame wars here and put efforts & creativity  
> in a
> concept on how to increase the usability and effectivity while
> maintaining the great flexibility, accuracy and traceability of GRASS.
>
>
>> As I tell frustrated students, a GIS is not like a word processor or
>> even a graphics program.
>
>
>
>> Although I, too, was initially turned off by this, I've become an
>> increasingly strong supporter of this approach over time. Sometimes I
>> even think that we would be better off to get away from all  
>> semblance of
>> word processor and graphic programs in the UI in order to make  
>> users to
>> think about GIS software differently.
> The problem is that creating some simple polygons in Google Earth and
> converting them to shapefiles via ogr2ogr gets you faster to a new  
> layer
> (e.g. for masking) than digitizing with traditional GIS programs.
> Also, not geo-educated staff understands Geobrowser. And geographical
> analysis often relys in interdisciplinary exchange.
>
> Thanks for your views as experienced user.
>
> Best regards,
> Timmie
>
>
>
>
>
> ------------------------------
>
> Message: 6
> Date: Sat, 04 Jul 2009 13:16:51 +0200
> From: Tim Michelsen <timmichelsen at gmx-topmail.de>
> Subject: [GRASS-dev] Re: [GRASS GIS] #668: export and share region
>        settings
> To: grass-dev at lists.osgeo.org
> Cc: grass-user at lists.osgeo.org
> Message-ID: <h2ogtl$3v0$3 at ger.gmane.org>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
>> I don't understand what you want to do here.
> Image the following use case:
> You have project location.
> Then you would like to test out some new processing workflows or
> developed a new methodology.
> In order not to pollute the project location with a lot of test  
> rasters,
> you start a new location to do the testing.
>
> It would be nice to have the save region settings available for /all/
> locations with the same projection.
>
>> If you are trying to use a region defined in one location within  
>> another
>> location, you can do that--at your own risk. Just copy the region def
>> file from location1/mapset1 to location2/mapset2.
> What is wrong with making the files in
> location1/PERMANENT/windows
> available to all locations with the same project in the GRASS  
> database?
>
> The region settings do not contain projection information.
> This may be changed in GRASS 7. Then, the GUI could show a list of
> region settings with the same projection when zooming to a saveed  
> region
> setting.
>
> There may be many users (regional government offices, unis with  
> studies
> in their neighborhood) how may also want this kind of sharing feature.
> This could increase usability of the map display in the GUI.
>
> The work the coders of the wxGUI did was a tremendous step towards  
> this
> direction!
>
>> care. I know it can be annoying sometimes for people coming from  
>> other
>> GIS programs, but GRASS has long had a philosophy of emphasizing the
>> importance of accurate digital mapping and cartography--something  
>> that
>> is probably tied to its primarily scientific, rather than commercial,
>> development and use.
> Commercial users do also need the best accuracies.
> But they seem to have also a high focus on the usability and  
> effectivity
> of use when performing all day tasks.
> And I cannot imagine that academia can affort wasting time in
> long-winded workflows.
>
>> The location/mapset structure is an important
>> aspect of maintaining that accuracy.
> Please let's not start flame wars here and put efforts & creativity  
> in a
> concept on how to increase the usability and effectivity while
> maintaining the great flexibility, accuracy and traceability of GRASS.
>
>
>> As I tell frustrated students, a GIS is not like a word processor or
>> even a graphics program.
>
>
>
>> Although I, too, was initially turned off by this, I've become an
>> increasingly strong supporter of this approach over time. Sometimes I
>> even think that we would be better off to get away from all  
>> semblance of
>> word processor and graphic programs in the UI in order to make  
>> users to
>> think about GIS software differently.
> The problem is that creating some simple polygons in Google Earth and
> converting them to shapefiles via ogr2ogr gets you faster to a new  
> layer
> (e.g. for masking) than digitizing with traditional GIS programs.
> Also, not geo-educated staff understands Geobrowser. And geographical
> analysis often relys in interdisciplinary exchange.
>
> Thanks for your views as experienced user.
>
> Best regards,
> Timmie
>

I don't want to sound grouchy and so start with a couple of disclaimers.

1. One of the features of GRASS that I often tout to others is the  
extent to which its capabilities are driven by the needs of the user  
base. GRASS users are important for generating ideas for improvements  
and new features, and for testing features. So I think that all user  
suggestions should be carefully considered.
2. I'm a very strong proponent of a rich GUI environment for GRASS-- 
and have written a lot of the code to create such environments in  
TclTk and wxPython

That said, I need to caution that just because something can be done  
in the GUI, doesn't necessarily mean that it should be done. And just  
because one user asks for a feature doesn't necessarily mean that this  
is best for the larger GRASS user community.

In the last few days, a lot of requests for GUI features have been  
made that implications for how users interact with the GIS Database/ 
Location/Mapset/region structure of GRASS. With GRASS 7 in  
development, this is a good time to think about and discuss this  
structure again. However, I'm not sure that simply responding  
incrementally to feature requests is a good way to go about this. One  
of the down sides of the way that GRASS has been developed is that a  
historical lack of coordination in the development of modules,  
libraries, and GUI has led to inconsistencies, hidden bugs, barely  
comprehensible code, and other such problems. A lot of effort is being  
made now to try and correct such problems.

If we want to consider loosening current restrictions on the way GRASS  
works with its file structure, projections, and regions, that's fine.  
But IMHO, we should do that explicitly rather than simply letting it  
evolve as it will. Do we want to allow users to more easily switch  
between locations or access files from multiple locations? If so, we  
should probably find a way to build in safeguards to ensure  
compatibility in projections so that we don't have to say 'do it at  
your own risk'. If we don't want to do this, then we should not  
implement backdoor methods via the GUI.

EPSG codes are a great convenience for setting projections  
**sometimes** but not always. Do we want to make more use of these? If  
so, then we should probably store the EPSG code in the PROJ_INFO file,  
where it is available to any module that needs it rather than using  
the GUI to track it.

Region portability could be useful. But how useful for how many users?  
It can also be dangerous since region extents in one projection will  
not correspond with the same extents in a different projection. If we  
want to make regions more portable, it might be better to alter  
g.region than to do this via the GUI.

Raster portability is also on the horizon with the restructuring of  
the file structure. But we need to do this in a coordinated way rather  
than hack it through the GUI.

Given the connection between the GRASS file structure and the way the  
software manages projections and maintains geospatial accuracy, asking  
that we consider these issues more carefully is not starting a flame  
war. It is simply prudent.

The other issue to consider is GUI complexity. Over the 5 years I've  
been coding the GUI, I've learned that it is a very tightly integrated  
and very complex system. Adding or changing a feature in one place  
runs a very real risk of breaking something somewhere else. And the  
more features added, the greater the risk--and the harder it becomes  
to track down the source of a broken feature. As much as I continue to  
support the ongoing development of a rich GUI, we don't want a buggy  
one. All changes need to be tested across multiple platforms now. And  
with Martin as still the only one actively coding the GUI right now  
since my summer research/travel schedule has changed, we're pretty  
short handed. So while Martin should get to choose what he wants to  
work on and do things that he enjoys, it's getting to a point that we  
might want to start setting some priorities for GUI coding--both bug  
fixing and enhancements. For example, there are still features that we  
are losing with the interactive xwin interface that have not yet been  
reimplemented in wxPython (e.g., training set creation for image  
classification and orthophoto rectification). Should these get a  
higher priority? In last year's Google SoC, Martin produced a  
fantastic, integrated 3D display. A lot of the initially bugs have  
been resolved, but it still doesn't work in Windows and is lacking  
many of the features of NVIZ. Should this be prioritized? Which GUI  
bugs should take the highest priority? And should bug fixing take  
precedence over rounding out the GUI features? That is, it is now time  
for the wxPython GUI to switch from experimental to developmental  
mode. Adding at least a little bit of structure would help me decide  
where to start and be most effective, at least, when I have time to do  
some more coding. It would also be helpful to anyone else who is able  
to help with the GUI coding. In appealing for a little more structure  
for continued GUI development, I think it would be best if this could  
be more of a group effort among the dev team. I'm not sure how best to  
organize this but think I should at least put the idea out there. We  
started a list in the WIKI when the new GUI project launched. We've  
accomplished a lot of this, but not all--and the new GUI has opened up  
new possibilities. GRASS has come a long way in usability in the last  
few years and I'd hate to lose the momentum and direction we've  
achieved.

Cheers
Michael