[OSGeo-Discuss] Thoughts on how to use elevation in routing

Stephen Woodbridge woodbri at swoodbridge.com
Mon Sep 13 16:28:06 PDT 2010


Bill,

Thanks for the ideas. I might try to do something with the viewshed idea 
in the future. It would need a LOT of computing to process all the road 
segments in a National dataset like Tiger.

But for now I would like to figure out the routing costs.

One idea I had was to compute the grade for a segment and then compute 
cost as:

cost = (time or distance) * scalefactor * max(abs(grade), 1.0)

This would have the effect of causing segments with a lot of grade to 
have a higher cost of traversal.

Or similarly, if you want to pick roads with a lot of elevation changes 
then use cost factor like:

cost = (time or distance) * scalefactor /
        abs(sum_elevation_changes_over_the_segment)

This would have the effect of decreasing the traversal cost for segments 
that have a lot of elevation changes.

These are pretty crude estimates and probably would need some fine 
tuning to get reasonable results.

Thanks,
   -Steve W

On 9/13/2010 4:24 PM, Bill Thoen wrote:
> Stephen Woodbridge wrote:
>> Hi all,
>>
>> (This is cross posting from the pgrouting list, sorry for the dups.)
>>
>> I have preprocessed some shapefile data and added elevation
>> information in the Z value of the coordinates. I'm wondering how to
>> best utilize that in routes and would like any thoughts or ideas you
>> might be willing to share.
>>
>> The obvious answer is to wrap the elevation data into the cost values
>> as this is simple and straight forward and does not require code
>> changes. This brings me to what have other people done or thought
>> about doing in this regard?
> Since you seem to enjoy large database problems, have you considered
> loading the DEM data together with the roads and sample the viewshed
> every few km? You could then create an objective cost factor for
> "scenic," proportional to the amount of land visible, with some
> adjusting factor that distinguishes morphology, land cover, or other
> weighted factors from each sample point. Creating a scale of "scenic"
> and "picturesque" as it goes form "ho-hum flatland" to "precipitous,
> brake-burning, wheel-gripping adventurous" might be fun all by itself.
>
> If you're looking for 3D ideas, there's a GIS consulting company across
> the hall from me that specializes in 3D information, visualization and
> analysis, and I know they are working on web services to deliver the
> sort of data that an application like yours would consume. Their website
> is full of 3D imagery, articles and examples that you might want to
> check out for ideas or inspiration There's a particularly good
> demonstration of using fog instead of shadow to create a visual
> representation of ridge lines, if your 're using those to determine a
> topographic index (see http://ctmap.com/serendipity/index.php).
>
> *Bill Thoen*
> GISnet - www.gisnet.com <http://www.gisnet.com/>
> 1401 Walnut St., Suite C
> Boulder, CO 80302
> 303-786-9961 tel
> 303-443-4856 fax
> bthoen at gisnet.com
>
> _______________________________________________
> Discuss mailing list
> Discuss at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/discuss




More information about the Discuss mailing list