[GRASS5] WWW-GRASS follow up

[David D Gray]

"Eric G . Miller" wrote:
> 
> 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).
> 

The new dig5 format will have a flat database structure, where the
attributes are indices referenced to another database which holds the
data, probably dbmi. But I think this is about the last hack that this
library can take. At the very least the vector engine needs
re-implemented to remove a lot of flotsam and jetsom left over from
previous versions, and maybe a redesign would be in order, though there
are features especially of spatial data handling that I think are well
represented in GRASS and should be preserved and enhanced. See my
remarks below.

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

Well as per my remarks above, it might not be a difficult thing in
principle, but the postgres (eg) connectivity would have to be
integarted more closely with the core API. The existing postgres support
works at module level, it allows data to be dumped to postgres and
queried, and after writing the connection is essentially lost.

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

On the whole I would agree with this. The SDTS standard includes a
description of the type of data that is the minimum structure for
various vector formats, presumably because they contain the minimum
required structures for any reliable reconstruction of topological
vector map data. Those are for intercahnge, but I think they adequately
describe resident data as well. Suitable geospatial vector formats are
networks, chains, 2d-manifolds and the like, not rings.

GRASS uses something like this. The `Level 2' format created by
including a dig_plus is built with v.build (probably should be a library
API call instead of a module). You might wonder if the vector data
should be built up from the simplest primitives, ie. points, organised
into chains, connected at nodes and so on, with all the more complex
structures built up from indexed forms of the primitive. A structure
like this (really a sort of graph or network) is built during import in
v.in.shape. But I found it is very resource hungry, so the existing form
where a series of points is the primitive, providing `chains' or edges
or polylines, with implicit nodes, is a good compromise: no topological
integrity is lost while it is faster and leaner. This is a description
of what is AKA `arc-node' format.

Ring->arc-node is not only more difficult, but I believe also more
intrinsically corruptible. When you try to edit whole ring structures in
situ, it doesn't matter how you code, because of the double digitising
over any line, the process is inherently unstable and leads to corrupt
data. Vector maps are like tech drawings, they're blueprints that need
to be built up in detail from the simpler primitives. The holistic
approach is what you take if you want a vector graphic image. However
because on-the-fly generation of rings from arc-node is so fast and
easy, it might be possible to include a rendered form of maps in a kind
of cache for display of finished maps - maybe querying, displaying,
labelling, manipulating purely as a graphic image - but not editing and
not as the definitive form of the map data.

David

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