[GRASS5] Proposal for a GRASS daemon to deliver metadata

[Robert Lagacé]

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,
> 
>  Markus
> 
> ----------------------------------------
> 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
Pavillon Comtois
Université Laval
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'