[postgis-users] Re: flow direction (pointer) indexing

[Robert W. Burgholzer]

List,
Thanks for all the feedback on this issue, I have been oput of town for
a couple of days.
Now, I am not overly experienced in this area, but I have done some work
with ESRI's map calculator, and I am favouring a vector approach for a
variety of reasons.
For another set of reasons I am interested in the spatial DB approach
vs. a full featured GIS approach. I am quite interested in hearing some
of the suggestions that you all may have (and will check out some of the
URLs given in last weeks mailings).

Here are a few of my thoughts on the matter:
Raster vs. Vector:
- SHAPE - rasters are limited to rectangular shaped divisions. Now, I
suppose that everything ultimately gets resolved down to a rectangle in
a computer system, but much of the data that we have available is in
irregularly shaped entities (such as soils maps), and my hope is to
create a generic meta modeling set of extensions which will not be too
restrictive in their input layers. I.E., require no conversions.

- MULTIPLE DATA VALUES (simplicity) - in the work that I have done with
rasters, they can only store a single value for each shape (someone
please correct me if I am wrong here). Of course, I could use shapes to
map data onto the raster, but then, why not use a shape?? Using the grid
calculations in arc---- leaves you with a host of intermediate layers
sitting around, of course this is easily remediable, but I like to
program my garbage collection. Als, it simply seems that rasters, as
efficent as they are, are less efficient from an interface
understandability perspective, and ultimately, if the number of data
fields required exceeds a certain number, the raster becomes a more
efficient option.

- MULTIPLE DATA VALUES (complexity) - I am interested in putting
together what I call an "Active Layer", that is, a layer which is
temporaly enabled, as well as being sensitive to other changes. For
example, a thiessen polygon layer which re-rendered itself in response
to a change in it's source point layer (achievable through database
triggers), or a rainfall layer, which would iterate through a sequence
of values at given time increments. My purpose for develping active
layers is to have truly integrated distributed hydrologic modeling in
the GIS. I thkon that they layer metaphor is a good one, and that a
surface runoff layer is much siompler than a macro which unites several
grid or shape layers into some calculation is more cumbersome.
Additionally, if I create this surface runoff layer as an entity unto
itself, then I can integrate with a seperate infiltration layer,
allowing me to desing my models in a modular fashion.

Gis vs. Spatial DB (SDB)
I think that the dawn of the age of the SDB is going to spell an end to
the classical GIS system as we know it. Already there are geoprocessing
routines being integrated into postGIS (as exhibited on this listserv
previously). The GIS systems' virtue is in its ability to provide a nice
interface, whish is of course essential, but it's role as an engine for
doing spatial comparisons and interactions may be superseeded by the
SDB. I think that from a performance standpoint, it might be argued that
we will ultimately get a higher performance from geoprocessing operation
done within the database than we will from a GIS acting overtop of it.
Additionally, I have a few personal reasons for doing this:
- TRANSPARENCY - I would like my "Active Layers" to be available in a
variety of GIS systems, thus, if I develop in postgres I should be able
to move to other GIS's simply, if not seemslessly. Of course, this is
provided the linkage to postgres in ESRI and others continues.
- DEVELOPER INTERACTION - I will be working on a team of modelers, and
to integrate the calculation functions into the database seems to be a
more easily shareable method.
- CHOICE OF LANGUAGE - if integrating into ESRI systems, it is a choice
of using postgres and C or ESRI and VB. I truly do not want to work in
VB from both a performance standpoint, and from a standpoint of
elegance.
- OBJECT ORIENTATION - I see the integration with an SDB as one which
will more readily lend itself to an object oriented modeling apporach.
As mentioned above, I want to be able to swap inputs and outputs for
various model active layers seemlessly, if I integrate into the backen
DB, they won't care whether they get input froma  static or active
layer, they will just be dealing with rows and columns of a DB. This is
not true object orientation of course, but it seems to be a good
approach froma  standpoint of speed.

I would like to hear any feedback regarding this.

-- 
Robert Burgholzer
al·go·rithm  n. 
       A step-by-step problem-solving procedure, especially an
established, recursive computational
       procedure for solving a problem in a finite number of steps.
Invented by Al Gore.
rburghol at vt.edu
http://www.soulswimmer.net/