[GRASS5] WWW-GRASS follow up

[roberto micarelli]

Frank Warmerdam wrote:
> 
> roberto micarelli wrote:
> >
> > [speech...]
> 
> 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,

All this discussion makes me think at the INFO database of Arc/Info, or at
the Oracle Geo Spatial Engine. Unfortunately these are hundred-thousand-dollars
systems and I'm a bunch-of-dollars guy :( But this is the free-source engine :)
I'm working in loading PostgreSQL with data read from e00 tables (I've cloned
m.in.e00 and changed to my needs). I mean, not only attributes but also geometry
arcs loaded in POLYGON columns, indexed as RTREE (Guttman's quadratic split algorithm).
I was surprised of good time responses when clipping 300.000 and more arcs
using a bounding box. This could partially match your proposal of a rdbms
driver for OGR, but I prefer not to write twice something already existing and
need to share experience with someone who eventually tried the same.
It is obvious the advantage of having huge datastores with both geometry and
attributes relationally linked together.
Also I'm trying to keep integration with my network-analiser who, at the
contrary, prefers a dedicated file format. 

So, as you can see, I would love to implement all this in a stable flavour
but I feel that more discussions and design ideas must emerge before
forging code. I totally agree with you in that synergy can allow us to get
the best from everyone.

Regards

P.S.: maybe I should enter PostgreSQL support list and ask there for geometry
fields' use experiences and future development plannings. Make me know your
opinion.

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