I had to subscribe to the list before being able to send this... this is
in reply to Philip Sargent's message. Note that replies may or may not
need to also go to osrs@remotesensing.org
... error message and long email headers cut out ...
Date: Thu, 06 Jan 2000 08:33:48 -0500
From: Allan Doyle <adoyle@intl-interfaces.com>
Subject: Re: [OSRS] Re: Future direction (and a rant).
To: Philip Sargent <Philip.Sargent@computer.org>
Cc: osrs@remotesensing.org, grass <GRASSLIST@baylor.edu>
Message-id: <48523314387499BC.4FAC582@intl-interfaces.com>
Organization: International Interfaces
MIME-version: 1.0
X-Mailer: Mozilla 4.7 [en] (Win98; U)
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7bit
X-Accept-Language: en,de
References: <00c201bf5847$05bd2f30$dac809c0@lslpc7.lsl.co.uk>
Since Philip cc'ed me in front of the world, here, I guess I'll chime in.
First off, I was the person at BBN responsible for the original
development of OpenMap (but not one of the principal coders of the Java
version), and was the person who convinced BBN to release it as open
source. Now I've started a company dedicated to building open interfaces,
currently focusing on GIS, but branching out into other areas. So much for
truth in advertising.
I always thought that OpenMap+GRASS would make a dynamite combination.
There would be many ways to go about it, given the current state (i.e.
flexibility) of OpenMap. (There are also some technical issues that would
need to be fixed).
At the same time, it might be a good idea to look at making a server
version of GRASS that could conform to the Open GIS Web Map Server
Interface spec (currently an OGC RFC, likely to become an OGC spec in
February - see http://www.opengis.org/techno/rfc10info.htm )
I can't devote enough time to be the lead that Frank was postulating, but
if there's enough momentum, I'd be happy to help look for some funding
sources to get this done (either OpenMap/GRASS or GRASS/WebMapServer).
Allan
Philip Sargent wrote:
Has anyone considered using OpenMap JavaBeans for this ? It would mean
writing a Java layer-viewer that understood GRASS as I understand it. [I
have never done this myself]. It is has an open-source-like license so
would match the GRASS user community well ?
See http://openmap.bbn.com/--Philip Sargent
www.laser-scan.com
[Personal opinion, not a company statement]-----Original Message-----
From: Frank Warmerdam <warmerda@home.com>
To: grass <GRASSLIST@baylor.edu>
Cc: OpenSource RemoteSensing <os-remotesensing@remotesensing.org>
Date: 05 January 2000 23:00
Subject: [OSRS] Re: Future direction (and a rant).>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@home.com
>light and sound - activate the windows |
http://members.home.com/warmerda
>and watch the world go round - Rush | Geospatial Programmer for Rent
>----------------------------------------
>Open Source Remote Sensing Project Discussion List
>To Subscribe: send a message to majordomo@remotesensing.org with
'subscribe os-remotesensing' in the body
>To Unsubscribe: send a message to majordomo@remotesensing.org with
'unsubscribe os-remotesensing' in the body
>To Report Problems: send a message to
owner-remotesensing@remotesensing.org
>
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Allan Doyle adoyle@intl-interfaces.com
International Interfaces +1 781 254 9484