[postgis-users] Elevation Profiles

[James Marca]

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?

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

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

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.

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

James