[postgis-users] Elevation Profiles

[strk at refractions.net]

I premit I've not experience with elevation grid.
Anyhow, here is my imagined algorithm:

	1: define a grid of C*R cells storing a list of Z values
	2: populate the cells Z list using a geometry, where
	   each vertex populates the cell it intersects
	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

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.

--strk;

On Mon, Nov 29, 2004 at 01:31:47PM -0700, ANDREW WOOLEY wrote:
> Thanks to everyone for the replies.  I finally realized that the reason
> that I don't get the results that I want is because of the bounding box
> issue.  It seems that I should be able to use a function like touches(),
> intersects(), contains() or similar to get the actual polygons from the
> elevation data set, but the queries take an absurdly long time. I worked
> this out to find that I am still getting inaccurate results.  So, it
> seems that I will be needing to do the step-through-the-vertices to get
> the profile that I need.
> 
> How do other programs perform this function? Is GMT the way to go?  I
> looked into it and since I am generating new trail segments from user
> input all the time, GMT doesn't seem like a workable solution. Looping
> through the vertices seems like more work than it should be.  
> 
> Any other ideas?
> 
> Thanks again for all who responded. 
> 
> Andrew
> 
> >>> jmarca at translab.its.uci.edu 11/24/2004 5:18:53 PM >>>
> At approximately Wed, Nov 24, 2004 at 11:46:31AM -0700, ANDREW WOOLEY
> wrote:
> > Folks,
> > 
> > I have been working on this idea for some time and have been trying
> to
> > implement elevation profiles and have yet to get it working like I
> want.
> >  I am hoping that someone has some good ideas for me.
> > 
> > Here is my problem. I have a series of lines in a table.  I also have
> a
> > table with elevations as polygons. I overlay them using this query:
> 
> > select e.gridcode as elevation from mtntrails_elevation as e, route
> as
> > r where e.the_geom && r.the_geom; 
> ...
> >  However, when I list out the elevations, they don't seem to be in
> the
> > "correct" order - that is the order I think they should be in.  The
> way
> 
> As far as I can see, you haven't asked postgresql to order your
> results, so you should expect them to be in no particular order.
> 
> 
> I think you need something like 
> 
> ORDER BY  r.timestamp
> 
> This is quite similar to something I am doing in my work.  I have gps
> points going into a table called observations.  After travel is
> complete, I collate observations into contiguous, continuous segments
> of travel, and I want to link these gps linestrings with Tiger/LINE
> complete chains for analysis.
> 
> Simply fetching the tiger complete chains that overlap my segments
> doesn't quite work.  The following SQL gets this overlap:
> 
> SELECT segment_id,ogc_fid,a.geom,c.geom 
>        FROM segment 
>        INNER JOIN segment_lines USING(segment_id)  
>        INNER JOIN geom_lines_32611 AS a ON line_gid=gid 
>        INNER JOIN ( 
> 	     SELECT b.geom,ogc_fid 
> 		    FROM geom_lines_32611 AS b 
> 		    INNER JOIN tiger_cc_lines ON b.gid=line_gid 
> 		    WHERE ogc_fid IS NOT NULL) AS c ON true  
>        WHERE segment_id=66781 AND a.geom && c.geom;
> 
> But there are two problems.  First I have the random sorting problem
> that you observed, in that the returned Tiger/LINE complete chain
> geometries are in *any* order rather than in the order that I crossed
> them.  Second, the && operator is a bounding box overlapper, so the
> longer my trip segment and the longer any nearby Tiger/LINEs, the more
> items are caught in the overlap.  In this case with segment_id=66781
> (arbitrary number), I get 93 matching Tiger complete chain line
> segments (roads).  
> 
> What I want to do is process the roads in order of appearance, so that
> I can build up a tree of *possible* links I drove along and then later
> reject those links which are obviously wrong as travel continues.  So
> I can't use the segment geometry (LINESTRING), but instead have to use
> the observation geometry (POINT), but with a join between segments and
> observations to allow me to select those points that belong in some
> arbitrary segment.  Using the observation geometry also allows me to
> get access to the time it was observed (the utc field, below).  The
> following SQL does this. 
> 
> SELECT id,utc,segment_id,a.geom,c.geom,ogc_fid 
>        FROM observations 
>        INNER JOIN obs_segment ON obs_segment.obs_id=id 
>        INNER JOIN obs_points ON obs_points.obs_id=id 
>        INNER JOIN geom_points_32611 AS a ON point_gid=gid 
>        INNER JOIN ( 
> 	     SELECT b.geom,ogc_fid 
> 		    FROM geom_lines_32611 as b 
> 		    INNER JOIN tiger_cc_lines ON b.gid=line_gid 
> 		    WHERE ogc_fid IS NOT NULL) AS c ON true  
>        WHERE segment_id=66781 AND c.geom && a.geom 
>        ORDER BY utc;
> 
>  (Note that I have observations in one table, and the geometries in a
>   separate table, geom_points_32611, and I join the two in a third
>   table, obs_points.  Similar for line geometries.)
> 
> Now I have the opposite problem from the previous SQL query.  The
> point-based query returns 15 rows, but it only includes 11 of the 14
> GPS observations that make up the segment in question.  The problem is
> that I am now overlapping a point with the bounding box of each
> individual Tiger/LINE complete chain geometry.  If the nearest
> complete chain is short, and if the GPS error is high, then the GPS
> point will not overlap any complete chain geometries.  I tried using
> buffer(geom,15), but that took forever.
> 
> So I am currently handling those cases in my perl code simply by
> making sure that my resulting complete chains form a connected graph,
> and fetching the missing links if they do not.
> 
> I don't imagine elevation data has any gaps, so this probably won't be
> a problem for you (every trail point will be in an elevation
> geometry).  
> 
> Hope that is relevant,
> James
> _______________________________________________
> postgis-users mailing list
> postgis-users at postgis.refractions.net 
> http://postgis.refractions.net/mailman/listinfo/postgis-users
> _______________________________________________
> postgis-users mailing list
> postgis-users at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-users