[postgis-users] flow direction (pointer) indexing

[Robert W. Burgholzer]

Steffan/list,
Ultimately my goal is to describe runoff from rainfall events. Basically
what I am focusing on is overland flow, that is, in a stream network, or
perhaps as a sheet (with an assumption of uniform flow across several
cells). I will be creating the networks in all cases as a consequence of
elevation differences in adjacent cells. It is the storage of references
to adjacent flow cells which I am concerned about.

As a consequence of elevation differences from cell to cell, a network
could be established by giving a spatial reference for the outlet and
inlet cells in the data table of the cell. This is as you describe, and
what I call a "pointer approach". This approach is valid for the case in
which you have flow which I'll call concentrated flow. The second case
that I see is one in which we have a sheet flow which may be described
by using a finite difference/element technique to solve a flow equation
numerically over several cells simultaneously. In this case, we must
know the flow depth in at least 2 adjacent cells. We can still use this
pointer approach in this case. My assumption is that the pointers would
be best done on an id column in this case.

A second approach would be to calculate flow direction on the fly using
the elevation of the current cell, and concept of the 'hydraulic head'
in the cell, which would allow a more flexible situation, such as one
which represents the overtopping of terraces and other flow control
structures. The hydraulic head would be a vector pointing in the
direction that flow "wants" to occur (based on elevation differences),
and the elevation of the water surface in the cell  relative to the
adjacent cells would determine if flow WOULD occur into a cell or not.
In this case, I believe I would need to do it spatially.

I will elaborate in SQL the cases I face:

CASE 1: POINTER APPROACH - STREAM NETWORK IS CALCULATED BEFOREHAND
select sum(b.qout) as inflow,a.gid from minihup as a,minihup as b where
a.gid = b.outletcell
       group by a.gid;

CASE 2: HYDRAULIC HEAD APPROACH
select a.depth,b.surface_elevation,a.roughness,a.slope from landtheme as
a,
       landtheme as b where a.contribcell_geom1 &&
b.hydraulic_head_vector 
       and a.surface_elevation <= b.surface_elevation

My question would be, in case 1, do I do an index on the gid column and
be done with it? Or should I do some sort of spatial index, and/or some
type of narrowing query to say "only need to search adjacent cells". In
CASE 2, is the spatial index sufficient (GIST) or do I need to do more?

I hope I was clear here, I am interested in any thouguhts.


Steffen Macke wrote:
> 
> > I am interested in an indexing scheme that will order line segments and
> > polyogn "cells" by a flow network, for the purposes of optimizing
> > hydrologic models done uysing postgis.
> 
> I've used a simple 'on-the-fly topology' water and wastewater networks
> consisting of lines and nodes in ArcView. The flow direction is simply
> defined by the digitizing direction of the line. If the flow direction
> changes, you have to flip the line. Traces through the network look
> up nodes and lines connected at the start and end points of a line.
> While the performance of this approach is not optimal, it is a very
> simple and intuitive way of storing the information. It should also
> be quite easy to visualize the flow direction. As PostGIS allows multiple
> geometry columns, you can add the start and end points of the lines
> as separate columns, which could help to improve the performance (depending
> on how many vertices your lines contain).
> 
> How do you create/edit your networks? I'm currently trying to implement a
> network editor for water/wastewater networks in Java that uses PostGIS
> for storage.
> 
> Steffen
> 
> _______________________________________________
> postgis-users mailing list
> postgis-users at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-users



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