[GRASS5] WWW-GRASS follow up

[Eric G . Miller]

On Sat, Oct 14, 2000 at 10:43:22AM -0500, Frank Warmerdam wrote:
> 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.  

GRASS doesn't have a very good concept of vector attributes to begin
with.  IMHO, GRASS needs a serious overhaul of it's vector format and
libraries.  It need both spatial and attribute indexing (presuming we
get some decent attribute handling).

But, as far as publishing GRASS data to something like PostgreSQL,
ORACLE or Informix (where there's a conception of geometry), I think it
would be pretty straight forward for whoever wants to step up to the
plate.  PostgreSQL has a little bit of a problem with the size of
tuples, but it does do a sort of indexing based on the bounding box of
POINT, PATH and POLYGON types (doesn't know about holes though).

> 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. 

The only comment I would make is the WKB is based on a complete object
geometry whereas something like GRASS uses an Arc-Node topology.
Translating from Arc-Node to Rings (Polys) is straight forward, going
the other way is more difficult.  IMHO, geometries like the WKB and
Shapefile are fine for data that's in a "finished" state, but create
some problems for data that will be edited.  I don't think it'd be too
hard to "present" GRASS data to a calling application as WKB to be used
for display or query.

I'd like to look at these issues more closely after we finalize GRASS
5.0.  I'm kind of in bug squash mode right now ;-0


-- 
/bin/sh ~/.signature:
Command not found

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