[GRASS5] Re: 5.1 architecture
John Reid
jgreid at uow.edu.au
Wed Apr 11 11:33:53 EDT 2001
Hi,
Apologies for the tardy reply. Any thoughts?
Eric G. Miller wrote:
> On Wed, Mar 21, 2001 at 07:23:13PM +1100, John Reid wrote:
>
>>> Yes, the architechture of the whole system is wrong...
>>
>> Care to elaborate? Do we have a better proposal? Or even just some rough ideas?
>
> Well, please understand my criticisms of GRASS are in good faith; I'm
> just a little frustrated with some elements of it.
Ditto - I suspect these might be common sentiments. It is always easy
to get frustrated with something you like ;-)
> Also, understand I'm
> a rank amateur when it comes to GUI stuff (generally it doesn't interest
> me much). But here are some of my observations:
I'm still a rank amateur when it comes to most of the development
issues. However, FWIW I'm currently more interested in the database
side, especially the data catalogs and metadata.
> The architechture for GRASS display was designed some 10+ years ago
> (??). Several decisions were made to focus on portability over
> functionality (probably a good thing). Among those decisions was to set
> up the display drivers as basically dumb pictures in which to paint
> pixels. A small amount of functionality was incorporated for getting
> mouse input. The design forced most of the hard work into the raster
> library and display modules (since it offers only a very primitive API).
> Unfortunately, it forces the display modules and raster library to be
> too intimate with the specifics of the display screen (screen coordinate
> translations is a good example). Also, there's very little "state"
> information that the display code can utilize (practically none).
> Anyway, much of this design seems to have been done well before X became
> a standard for *nix and hence drivers had to deal with the vagaries of
> entire graphics subsystems -- so, a limited command set made driver
> author's job easier.
>
> I really don't have a coherent picture in my mind of what a new system
> would/should look like. Basically, I think the display driver should
> know how to draw map elements directly (i.e. they should be built in).
> It should know about the current coordinate system (as well as its
> screen coordinate system) and be able to make the necessary translations
> on the fly. It should know what map layers it is currently displaying,
> and be able to dispatch the appropriate handler whenever a
> resize/redraw/query event occurs. Basically, the system needs to be
> designed to be responsive to the user.
>
> I realize eliminating the display module <=> display driver separation
> would make things like the CELL or HTMLMAP driver harder to implement.
> As far as something like CELL, I think it could be better replaced by
> an improved map scripting => output system. I'm tending to think
> HTMLMAP functionality could be accomplished fairly easily with a vector
> command and arguments giving image size (for scaling).
>
>
>>>> If I could I would start over using the GRASS library as the starting
>>>> point creating a framework for model, view, and control commands but
>>>> I'm only one person and I have to work within my limits. As such I can
>>>> work with the current flawed framework (time permitting).
>>>
>>> Pretty much have to start from scratch I think...
>>
>> Or could we rebuild the core libraries and define new API's (for 5.1? though
>> probably slightly longer term), then provide wrappers around the new code so
>> existing commands don't break? Should be possible for at least part of the
>> library, such as the catalogue services and region of interest - though as a
>> newbie to grass I could well be wrong about that ;-)
>
> There's too much of this wrappers around old code stuff already. It
> tends to compound on itself making the system less flexible and less
> maintainable over time. Sometimes it's better to break stuff. Of
> course, we should have a firm idea of what the plan is...
Is the other way round feasible? I was thinking more in terms of an
interface wrapper of C-linkage code to provide the current
functionality (API) sitting over new "core" interfaces (API's, service
interfaces). That way I was hoping we could provide extended
functionality while existing programs would not break (yeah, I am
optimistic sometimes ;-) Possible?
This might also enable use of C++, CORBA, and other technologies if it
is judged desirable. I gather there is some interest in this.
See below for some more details of what I was thinking.
> I hope I've made some sense and I hope to see more discussion (and
> hopefully code) come out of this. In general, I'd like to see some more
> reevaluation of the system architechture as a whole. There are several
> areas that I think could be much improved if we did some brainstorming
> on how elements of the architechture could be better. Right now,
> there's a feeling we just need to get something out the door (I tend to
> agree with this sentiment...). But I think it's worth developing a
> longer term road map about how we want to see GRASS evolve.
>
> Ciao,
In Re: [GRASS5] Re: Created maps not appearing -Tough problem, Markus
Neteler wrote:
> Hi all,
>
> this appeared on "grasslist" today (you will have seen it).
>
> On Wed, Apr 04, 2001 at 09:15:12PM +0930, Gail Higginbottom wrote:
>
>> Hi Markus and Grass members
>> ,
>> sorry to be writing all the time. You may have seen on the list that I
>> have imported a number of Ordnance Survey files of the UK using r.in.rtf2.
>>
>> It seemed to work last night and I managed to view the raster files
>> straight after creating them. I then came up with the first problem of
>> the data falling out of the current and default region when creating
>> these.
>
> a feature which auto-extends the GRASS default location was integrated into
> r.in.gdal by Frank Warmerdam (-e flag). I suggest to include this flag
> into all import modules.
> Perhaps we generally should re-work the location management for 5.1.
>
> Just my 0.02 Euro
>
> Markus
Start with location management, data catalog and metadata services?
From what an admittedly naive perspective, it seems to me that this
area might be amenable to the approach outlined above. Currently
management of these seems to be provided by a combination of:
* API functions
* Commands
* Files
* Environment variables
I have had a quick go at identifying some potential areas where this
might be implemented:
Mapsets (data catalogue?)
-------------------
* $GISDBASE/G_gisdbase
* $LOCATION_NAME/G_location
* $MAPSET/G_mapset
* GROUP
* SEARCH_PATH
Regions (view extents?)
------------------
See GRASS Programmers Manual Section 9.1
Commands:
* g.region
* d.zoom
* r.mask
Files:
WIND
MASK
Functions - see GPM Sec 12.7.1 for managing the database region.
Layers
-----
g.list
See sections on Vector and Raster libraries?
GISRC
------
????
What else? Am I missing something that would be a show-stopper?
Two other questions. Has anyone done any comparisons of the data models
and interfaces defined to handle data catalogues and metadata between
any of the following standards:
* ISO draft specification catalogue and metadata schemas;
* OpenGIS SF-CORBA and SF-COM specifications;
* OGDI API;
* SDTS API?
Are there any other sources of information about GRASS and CORBA apart
from the link on the grass web page?
Finally, does any of this make some sense for an approach that could be
adopted for 5.1 (or later)?
cheers
----------------------------------------------------------------------
john reid e-mail john_reid at uow.edu.au
uproot your questions from their ground and the dangling roots will be
seen. more questions!
-mentat zensufi
apply standard disclaimers as desired...
----------------------------------------------------------------------
----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo at geog.uni-hannover.de with
subject 'unsubscribe grass5'
More information about the grass-dev
mailing list