[OSRS] Re: Future direction (and a rant).]
Allan Doyle
adoyle at intl-interfaces.com
Thu Jan 6 08:52:10 EST 2000
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 at remotesensing.org
... error message and long email headers cut out ...
Date: Thu, 06 Jan 2000 08:33:48 -0500
From: Allan Doyle <adoyle at intl-interfaces.com>
Subject: Re: [OSRS] Re: Future direction (and a rant).
To: Philip Sargent <Philip.Sargent at computer.org>
Cc: osrs at remotesensing.org, grass <GRASSLIST at baylor.edu>
Message-id: <48523314387499BC.4FAC582 at 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 at 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 at home.com>
> To: grass <GRASSLIST at baylor.edu>
> Cc: OpenSource RemoteSensing <os-remotesensing at 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 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
> >----------------------------------------
> >Open Source Remote Sensing Project Discussion List
> >To Subscribe: send a message to majordomo at remotesensing.org with
> 'subscribe os-remotesensing' in the body
> >To Unsubscribe: send a message to majordomo at remotesensing.org with
> 'unsubscribe os-remotesensing' in the body
> >To Report Problems: send a message to
> owner-remotesensing at remotesensing.org
> >
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Allan Doyle adoyle at intl-interfaces.com
International Interfaces +1 781 254 9484
More information about the grass-user
mailing list