[GRASS-dev] some questions about future development

Michael Barton michael.barton at asu.edu
Mon Aug 18 11:13:49 EDT 2008


On Aug 18, 2008, at 1:25 AM, <grass-dev-request at lists.osgeo.org> wrote:

> Date: Mon, 18 Aug 2008 10:25:30 +0200
> From: "G. Allegri" <giohappy at gmail.com>
> Subject: [GRASS-dev] some questions about future development
> To: "GRASS developers list" <grass-dev at lists.osgeo.org>
> Message-ID:
> 	<e12429640808180125g69572060w48d1dc766244e722 at mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> Hi to everyone.
> In the last period I've been working a lot with GRASS for my daily  
> job, and
> it permitted me to develop a series of wishes for the future...
> I will share them in the GRASS 7 ideas collection but I would like  
> to ask
> some questions before:
>
> VECTORS
>
> 1 - OGR datasources: one important GIS functionality in daily work  
> is the
> possibility to access shapefiles, and other simple feature datas  
> (PostGIS,
> Oracle Spatial, etc.) directly, without having to import them and/or
> building the topology. Many times these datas are simply used for
> visualization (geometries and attributes), or table attributes  
> management...
> I've seen it is already in the Radim's TODO list [1].
> Is it a priority in GRASS 7 development, or it is left as a minor
> enhancement?
>
> 2 - geometry highlighting: when selecting features from the  
> attributes table
> (wxGUI), it would be nice to make the geometries highlighted in the  
> map
> window... See next section.
>
> 3 - vectors/thematic vectors: it happens only in GRASS that these  
> two are
> separated. Wouldn't be better to merge into a single display command  
> with
> thmatic styiling as options?
>
> MAP CANVAS
>
> the user experience with the maps should be enhanced:
>
> 1 - when zooming, incremental resolution would be nice (pyramids for
> rasters?)
> 2 - when panning, only the new areas should be added (a sort of  
> tiling)
> 3 - geometry selection (like with "identify" tools, or polygonal  
> selection
> tools) ->view selected features inside the table attributes, and  
> viceversa
>
> I know it is quite distant from the actual display architecture, but  
> it
> would be an important improvement from my point of view...
> Do you think it will be feasible considering the rodmap you've  
> planned?
>
> Ok, it's enough for now. I would have many other proposals, but I  
> will share
> them in the future :)

Just a note to the development team. Except for #1, these are all GUI/ 
interface issues. I haven't calculated the size of the wxPython code  
base, but when I checked about a year ago, the TclTk code took up over  
18,000 lines of code. The many C modules are what makes GRASS 'work'  
and makes it a powerful spatial data management and analysis tool. But  
the GUI is the 'face' that most people see and work with on a daily  
basis. Glynn's rewrite of the display architecture will have an  
important effect on the way the GUI connects with modules. But there  
is still an awful lot of wxPython code to enhance, maintain, and still  
to write. So if any of you would like to try your hand at Python and  
wxPython, we'd welcome another volunteer or two to the GUI development  
team.

Michael


More information about the grass-dev mailing list