[GRASS5] WWW-GRASS follow up

[Frank Warmerdam]

roberto micarelli wrote:
> 
> I've tryied to ask Federico some questions and I mentioned MapServer. I was going to
> try things similar to the excellent work of Federico but stopped when I found MapServer
> a ready to use system.
> However there are issues...
> Map Server is currently fully supporting shape file, and partially SDE (no query support).
> It is not a full functional GIS, GRASS offers more support on this side.
> It is going to support OGR, and consequently OGCI with query support.
> Lacks a rdbms interface...
> On the other hand MapServer has a powerful CGI interface based on templates and
> configuration files 'dramatically' similar to the one written by Federico.
> I'm still confused (and now more than before) on what to use for web interfaces.
> I'm also 'afraid' that while free-source world is going to support HTML based web
> applications, vendors' world is moving toward XML and content abstraction approach.
> A component interface to follow this trend would be welcome!

Roberto, 

A few notes that might (or might not) complicate things. 

 o It is my hope to integrate GDAL into MapServer, and GDAL now has good 
   support for GRASS rasters via libgrass. 

 o I would like to see libgrass eventually include the vector API, at which
   time I would see extending OGR to include GRASS vector support also putting
   it within MapServer.

 o A significant issue for mapserver applications is _optimized_ access to 
   vector data.  It isn't clear to me that the current GRASS vector structures
   support optimized spatial or attributes queries, correct me if I am wrong.
   There has been talk of overhauling the GRASS vector API, and I think that
   would be a good opportunity to build it as an optimized datastore for vector
   information with fast spatial and attribute queries.  It might be that 
   the new vector API supports a variety of possible datastores including 
   a simple file based datastore (fitting nicely within the current GRASS 
   database heirarchy) and a more sophisticated RDBMS based datastore which
   could be in PostgreSQL, MySQL or even a commercial DB.  

In the meantime I think you could do well for fairly static applications with
a wholesale conversion of your datasets to Shapefiles for fast and efficient
access.

PS. You mention that OGR lacks a RDBMS interface.  I would be pleased to see
an OGR interface to a database, and I don't think it would be that difficult
especially if the geometry was just kept in "OGC Well Known Binary" format.  
I see alot of potential for synergy between projects like MapServer, FMaps, 
OSSIM and interoperability technologies like OGR, OGDI and OGC Simple Features 
if we (the GIS free software community) could "get behind" a database methology 
for storing vector data. 

Best Regards,

---------------------------------------+--------------------------------------
I set the clouds in motion - turn 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

---------------------------------------- 
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo at geog.uni-hannover.de with
subject 'unsubscribe grass5'