[GRASS5] Re: An internal db for GRASS

[Eric G . Miller]

On Sun, Feb 11, 2001 at 01:22:26AM +0000, David D Gray wrote:
> Rich Shepard wrote:
> > 
> > On Sat, 10 Feb 2001, Roger S. Miller wrote:
> > 
> > > Forgive my ignorance, but...
> > 
> > Roger,
> > 
> >   Welcome to my club! :-)
> > 
> > > Postgres handles geometric data -- points, circles, polylines, polygons
> > > and so on -- and includes functions to determine if a point is in an
> > > area, two lines intersect and others (but no sort of raster
> > > functionality).  How different is that from handling spacial data
> > > structures?  Are those structures something that for some reason
> > > couldn't be addressed as a user-defined type?
> > 
> >   I know it does. When I brought this up months ago, I was told by those who
> > I assume know much better than I, that it was not suitable for an arc-node
> > format such as GRASS.
> > 
> >   Thinking about this just now, it occurs to me that we'd use points and
> > arcs as graphic types. The problem is that postgres does not handle
> > topology. 
> > [...]
> 
> Hi,
> 
> Yes, I would agree that is possible. This recently occurred to me also. 
> 
> >   Looking at ARC/Info export data, I see that vectors have attributes such
> > as LPOLY, RPOLY and so on. Is this computationally too difficult to store in
> > a postgres database along with each spatial arc or point? I don't know.
> > 
> 
> Not at all. The build process would just write this data using
> Postgresql's API.
> 
> The problem is that this is absurdly inefficient for large volume
> spatial data, if you are using SQL. It would probably be necessary to
> hack some kind of API out of Postgresql itself, to provide lower level
> access to the underlying database structures.
> 
> [I am assuming there _is_ no low-level API in PostgreSQL, as I see
> nothing in the various language API's documentation to suggest it. But
> does anyone know better...?]

Server Programming Interface (SPI), and/or custom modules (I have some
experience writing these for PostgreSQL).  I haven't played with SPI,
but I'd think it'd be necessary for setting up handlers.  In the end,
with PostgreSQL, you still have to pass data as text (unless using large
objects).  There is some mechanism for doing RPC calls and passing in
binary data (but it's not well documented, nor is it promoted).  You can
use binary cursors for selects (but the data better reside on a machine
with identical architecture, or translations will be required).

> >   Sure, raster data is handled well internally and we don't want/need to
> > mess with that. But, multi-attribute sites data and vector data are a
> > different story.
> > 
> >   I have a bunch of questions directly related to this point, but that'll be
> > the subject of a separate message later today.
> > 
> 
> Perhaps anticipating.. there are distinctions between the
> spatial/geometric/positional characteristics of a vector map, and those
> that are to do with topological structure. 
> 
> We have been discussing recently the changes needed for GRASS5.1, and an
> idea that has been floated is to incorporate a second persistent binary
> file which will be a spatial tree representation of the map, providing
> easily accessed information allowing spatial queries on the map, much as
> the dig_plus provides persistent information about the topological
> links. Only a topologically aware vector map (Level 2) could be mapped
> this way, so it might be an optional new `level 3' build.
> 
> Also, every entity in a map would have a unique object ID, providing a
> link between the spatial data and records in a database.

Sounds about right to me.

-- 
Eric G. Miller <egm2 at jps.net>

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