[GRASS5] Proposal for a GRASS daemon to deliver metadata
lagace at echo.grr.ulaval.ca
Wed Aug 30 09:52:45 EDT 2000
Markus Neteler wrote:
> Hi all,
> concerning the daemon discussion (to daemon or not to daemon):
> We are currently facing a set of problems which should be fixed
> in near future. If a daemon is required - I don't know.
> THe problems are totally different, some of those listed
> below might belong to another discussion.
> What's required (partly already implemented):
> - external applications like "R" needs to get the
> metadata (location, mapset, resolution, projection)
> - external applications should be able to set new
> location parameters easily (like R, web applications,...)
> - if storing entire datasets into PostgreSQL (or another DBMS)
> the metadata needs to stay somewhere. Suppose we
> analyse GIS data in R, taking vectors directly from
> GRASS using the GRASS/R interface and taking raster data
> delivered by PostgreSQL (using the RPgSQL or RODBC proxy),
> how to keep the location settings in sync? The basic
> problem will arise from data storage in PostgreSQL
> if one wants to analyse a subset of data only.
> - database locking will be required (already implemented)
> - but: concurrent GRASS sessions should be possible, at
> least with different locations (so a daemon could check
> for conflicts, environment variables might not be sufficient)
> - changing location on-the-fly should be possible (daemon
> might not be required)
> - the monitor should be closeable by click without the
> "d.mon stop" command (for user's convenience). This will
> require the fifos exchange to a sockets concept
> - monitor locking is required (already implemented)
> Most of these topics are concerning user's convenience. For
> wider GRASS acceptance I feel we should take care of this.
In our project, we want to interface GRASS, agricultural models
(like EPIC, CERES, CARE) to a common database. We area facing
the same problem. On a theoritical point of view, all data
(including the metadata) should be in the database. Database
management softwares (DBMS) offer tools for looking records and
other data management functions. DBMS looks like daemon for
the application. The DBMS is able to perform the functions that
you are wishing for the daemon. For the old GRASS data structure
(using flat files), a daemon is require and one possibility to
investigate is to create a daemon that mimic the DBMS interface
such as OBDC. With this approch, any GRASS application could
interface to any DBMS or conventional GRASS data transparently.
For the DBMS, the metadata structure needs to be define which
needs some work. Our analysis (which is begining) could be a
base of discussion. This approch is in the OPENGIS direction.
This only one opinion that I hope will fuel other reflexions.
> Just some discussion comments,
> If you want to unsubscribe from GRASS Development Team mailing list write to:
> minordomo at geog.uni-hannover.de with
> subject 'unsubscribe grass5'
Robert Lagacé, professeur
Ste-Foy, Québec, G1K 7P4
tel : (418)-656-2131#2276
Fax : (418)-656-3723
E-mail : lagace at grr.ulaval.ca
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