On Jul 5, 2009, at 2:52 AM, grass-dev-request@lists.osgeo.org wrote:
Date: Sat, 04 Jul 2009 23:28:46 +0200
From: Tim Michelsen <timmichelsen@gmx-topmail.de>
Subject: [GRASS-dev] Re: [GRASS GIS] #668: export and share region
settings
To: grass-dev@lists.osgeo.org
Cc: grass-user@lists.osgeo.org
Message-ID: <h2ohie$4iu$3@ger.gmane.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowedI 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@gmx-topmail.de>
Subject: [GRASS-dev] Re: [GRASS GIS] #668: export and share region
settings
To: grass-dev@lists.osgeo.org
Cc: grass-user@lists.osgeo.org
Message-ID: <h2ogtl$3v0$3@ger.gmane.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowedI 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