[GRASS5] Re: An internal db for GRASS

[David D Gray]

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

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

Regards

David

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