Future direction (and a rant).
Frank Warmerdam
warmerda at home.com
Wed Jan 5 17:17:45 EST 2000
Angus Carr wrote:
>
> Based on one day's return comments, people on this list see the
> "arcviewization" of GRASS as a good possible thing.
Angus,
I am not sure describing it as the arcviewization of GRASS is the
best way to develop support for your idea. :-)
> If we are to invent a multi-windowing, properly GUI system, we will need
> to allow multiple concurrent sessions of GRASS, which is desirable
> anyway, change the way windows are drawn on the screen, and modify the
> parser. I'm sure that isn't all.
>
> This is not a project to undertake without thought, and I don't want to
> do it all myself. I think all the small improvements to the main
> components of grass will improve the rest of the system too.
>
> my personal pet idea is to change the system a little to allow GRASS
> commands and video stuff and text stuff to pass down sockets, and then
> decouple the display from the processing machine. This is of course a
> basically silly idea, but I like it.
My personal opinion is that GRASS needs a friendly data viewing environment
more than it needs a friendly interface to the analysis commands. By this
I mean a relatively simple GUI in which you can load various layers of
raster and vector data, browse around, select objects and inspect attributes.
That sort of thing.
Hooking GRASS analysis commands as is done by tcltkgrass, or something slightly
more radical is also desirable, but I think is of lower priority than
establishing an easy to use data viewer.
In an ideal world, such a data viewer might not even be limited to use with
the rest of GRASS. For instance, it would be nice to use a multi-format
data access library, so that it could be used directly to view and analyse
data in various formats. Such an approach might make it possible to get
people who aren't already GRASS users interested in developing the application.
Depending on the level it is desirable to take such an application, it can be
a few man-months of effort or many man years of effort. It isn't clear that
the GRASS community can sustain a multi-man year effort so something modest might
be more appropriate.
I can see a few major decisions to make:
o What language to implement it in? Tcl is an option, but not one I favour
myself. It seems to me that the larger Tcl applications get, the buggier
and slower they get. While Tcl might be an appropriate extention language
for such a viewer, I don't feel the viewer should be implemented in Tcl.
My normal bias would be to implement it in C, or now days C++.
o What GUI toolkit to use? If it isn't all done in Tcl, then there is the
question of display technology. It could be written directly to the X API
for graphics, or it could use gtk, or Qt, or perhaps something else. I am
not really happy with any of the available options, though it seems that
gtk (or gtk++?) has substantial momementum in the open source community, and
some reasonable hope of porting to Windows (which I consider important).
o How closely is it related to the existing GRASS driver technology? Does it
attempt to maintain some level of compatibility with the existing GRASS
display driver approach? Based on experience from a similar quandry at PCI
some years ago, I think it is a bad idea to make this a "smart GRASS display
driver". I think this would make it difficult to make the application
respond intuitively, but then I don't understand the existing driver
technology well, so I could be wrong.
o How closely does it relate to the existing GRASS data model? While it is
obviously necessary to be able to display and inspect GRASS data smoothly,
I don't think the limitations of the existing GRASS vector data model should
be embedded in the viewer. On the raster side, I am not so aware of problems.
I am also not convinced that the viewer should be restricted by the GRASS
concept of a mapset having a fixed projection (and extent?).
o What sort of commandline interface would be available? I think Tcl would be
a reasonable choice for an extention language. At worst a shell script should
be able to send "extention language script" to the program, and get back some
sort of response.
It would also be nice if the viewer would "notice" user changes to displayed
layers (due to users running commandline GRASS programs), and automatically
update the layer on the display.
The biggest question is how would such a project be resourced? Would we try to
convinced Baylor to front most of the effort? It seems to be that they are
stretched pretty thin with the existing GRASS 5 conversion and maintenance of
conventional GRASS. Ideally the project could be done in "true open source
fashion" in a distributed way, and attract effort from many in GIS and
Remote Sensing that are not normally GRASS users, if we can convince them that
the resulting tool will have broad usefulness outside of just GRASS. I am
cc:ing this message to the main remotesensing.org mailing list, because I
think that this would be one community that could benefit from a freeware
raster/vector data viewer.
Furthermore, we need a project leader who is willing to commit substantial
effort, likely developing a prototype implementation quickly before opening
the project to wider input. While I could do this, it isn't what I have
decided to work on, and I wouldn't want to do a half-assed job. Personally
I doubt we will get a project leader willing to commit sufficient effort and
who could pull it together, but if we do we will be away to the races.
One final note, I mentioned that I think it should be built on multi-format
vector and raster libraries. This is my area of interest, and I would be
willing to do substantial work to make my raster and vector multi-format read/
write libraries available, and tailoring them to the needs of such a viewer.
Best regards,
---------------------------------------+--------------------------------------
I set the clouds in motion - turned up | Frank Warmerdam, warmerda at home.com
light and sound - activate the windows | http://members.home.com/warmerda
and watch the world go round - Rush | Geospatial Programmer for Rent
More information about the grass-user
mailing list