On Aug 18, 2008, at 1:25 AM, <[EMAIL PROTECTED]> wrote:
Date: Mon, 18 Aug 2008 10:25:30 +0200
From: "G. Allegri" <[EMAIL PROTECTED]>
Subject: [GRASS-dev] some questions about future development
To: "GRASS developers list" <grass-dev@lists.osgeo.org>
Message-ID:
<[EMAIL PROTECTED]>
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
_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
