[postgis-users] Elevation Profiles

[strk at refractions.net]

On Tue, Nov 30, 2004 at 01:44:15PM -0800, James Marca wrote:
> At approximately Tue, Nov 30, 2004 at 11:19:20AM +0100, strk at refractions.net wrote:
> > I premit I've not experience with elevation grid.
> 
> I'm also clueless on using elevation grids. But I'm going to comment
> and hope someone will correct my misinterpretations
> 
> > Anyhow, here is my imagined algorithm:
> > 
> > 	1: define a grid of C*R cells storing a list of Z values
> 
> Does it have to be a grid, or can it be any sort of tessellation, such
> as a Delaunay triangulation?  
>
> > 	2: populate the cells Z list using a geometry, where
> > 	   each vertex populates the cell it intersects
> 
> Couldn't the defining geometry create the Delaunay triangulation?  So
> that each valid elevation point (z value) inhabits its own triangle?

In this case each valid elevation point would define a vertex of a
triangle, wouldn't it ? After gathering all input geoms, and thus
vertexes the triangulation will need to be computed, connecting 
them. But is this worth the cost of doing it ? 

> 
> > 	3: elevate a geometry applying for each vertex 
> > 	   the average Z of the cell it intersects and
> > 	   the average Z of the whole grid for cells with
> > 	   no Z in list
>  
> Would applying a kriging scheme work better for defining the cells
> with no Z.  Kriging is computationally expensive and application
> specific, but it was my understanding that spatial averaging really
> mean you need to do kriging to get around the autocorrelation
> effects.  Perhaps nearest neighbor averages is good enough for
> elevation, and a hook can exist for more specialized subclasses?

For sure defining elevation for unsampled cells can be smarter.
Maybe each elevated cell could pull up it's neighbors by a function
of its own elevation. Ie:

	x x x x x        1 2 2 2 1
	x x x x x        2 3 4 3 2
	x x 8 x x  ===>  2 4 8 4 2
	x x x x x        2 3 4 3 2
	x x x x x        1 2 2 2 1

Note that each cell contains a list of Z values, so 'pulls' from 
different elevated cells will be merged averaging the assigned Zs.

> But I confess I am confused by this step, what exactly is being done.

The idea is that each of the 'unelevated' vertexes in the geometry to be
elevated gets it's elevation from the grid cell it falls into.

> Finally, elevation is a special case of any continuous, spatially
> and/or temporally distributed value.  To the extent that it isn't a
> barrier to implementation, it would be nice if the same mechanism
> could be used for storing other data.  For example, measured speed of
> traffic flow (by time of day), air quality values, tree trunk
> circumference, etc.  I ask because I am currently storing GPS
> positions as a POINT geometry, but I cannot do the same for the speed,
> and must instead maintain a separate table which has to be
> linked/interpolated by an external program.

The grid could support any kind of value, as far as the heuristic
defined for value propagation is meaningful for that specific kind
of dimension. 

> 
> > I've implemented this in GEOS, but there's no interface to geos
> > yet. Anyway, given the simplicity of the code I'd rather reimplement
> > it natively in postgis.
> > 
> > The grid-defining geometry could be any geometry, to increment
> > precision this would probably be a multipoint.
> > Defining a new postgis datatype could also be nice, and we could
> > have geometry->grid cast do grid population.
> 
> How many dimensions can a POINT have?  Could anything above 2 be used
> to populate separate grids?  

GEOS does only support 3d POINTS.
Upcoming POSTGIS 1.0 supports 2d/3d/4d.
A postgis implementation could allow for 4th dimension
sampling distribution.

> 
> James

--strk;