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

Tue Sep 14 10:41:28 PDT 2010

Yes, this is another good factor to look at. Curvature can be computed 
as the 2nd derivative or the rate of change in angle along the road. 
This is a little harder to compute with segments as you need to join 
adjacent segments to compute this or you get disconnects where they 
join. And you have to figure out what are "through" streets at 
intersections of more then two segments. But still a good measure.

Also "curvyness" can often com into play when following rivers and 
streams even when there is not significant grade.

-Steve

On 9/14/2010 12:52 PM, Richard Greenwood wrote:
> I think "cruvyness" might also be a useful resistance factor, and it
> is often associated with grade, as in steep mountain roads with lots
> of switchbacks. After attending FOSS4G last week my wife and I have
> been driving and biking in the Pyrenees and experiencing the effects
> of both cruvyness and grade on our travel times.
>
> Rich
>
> On Tue, Sep 14, 2010 at 10:31 AM, Stephen Woodbridge
> <woodbri at swoodbridge.com>  wrote:
>> On 9/14/2010 11:43 AM, Bill Thoen wrote:
>>>
>>>   Steve,
>>>
>>> Adding viewsheds to the package would certainly up the computing costs;
>>> I was wondering if you had a limit to what sort of processing power
>>> you've got there. ;-)
>>
>> It is not unlimited, so part of the problem that is interesting to me is how
>> to find and compute economical way to do it.
>>
>>> I also think what you're proposing might be interesting, but you have to
>>> be careful about what conclusions you can draw from it. At what point
>>> does the cost due to gradient variations become insignificant to the
>>> overall cost of a route for a particular type of vehicle? For a trucker
>>> on an interstate highway it doesn't signify because the statistical
>>> noise of factors such high speeds and short driving time balanced
>>> against the higher price of fuel, services and road freight taxes
>>> completely overwhelms the cost factor contributed by the change in
>>> gradients. So in those cases you'd be computing numbers but not saying
>>> anything.
>>
>> Agreed, doing anything for the trucking industry that would be useful
>> probably requires a lot more understanding of the industry and regulations
>> required for that. Luckily it is not my main focus :)
>>
>>> A different scenario, where gradient /is/ a significant factor, would be
>>> a three-day 100 mile bike ride event through the mountains (like the
>>> 'Ride the Rockies' event they hold around here every year.) The power
>>> that bicyclists can produce is so low that speeds and endurance are
>>> strongly affected by grades. But a bicyclist doesn't typically operate
>>> on the scale of the nation so applying the calculations to the entire
>>> TIGER file is overkill. Also, the bicyclist operates on such a large
>>> scale that the source data you're using to calculate gradient (30m DEM)
>>> may be too coarse to be reliable on the bicyclist's scale.
>>
>> Right, these points are all valid and have crossed my mind at one point or
>> another. Applying this to the Tiger data set is not that big of a deal. I
>> already have the Tiger data in XYZ so computing grades is not that
>> difficult. Another reason for applying it to the whole data set is to build
>> a web portal with US coverage. Granted any single route will not have
>> continental scope, but individual routes might be anywhere on the continent.
>>
>>> I'm not saying it isn't worth doing, I'm just saying you'll need to
>>> qualify the precision of your results before you can say much about
>>> applying this to any real-world problems.
>>
>> I'll post a link back if I get anything working. Meanwhile, thanks for the
>> ideas and thoughts.
>>
>> -Steve
>>
>>> - Bill Thoen
>>>
>>>
>>> On 9/13/2010 5:28 PM, Stephen Woodbridge wrote:
>>>>
>>>> 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
>>>>
>>>> _______________________________________________
>>>> Discuss mailing list
>>>> Discuss at lists.osgeo.org
>>>> http://lists.osgeo.org/mailman/listinfo/discuss
>>>>
>>>
>>> --
>>> *Bill Thoen*
>>> GISnet - www.gisnet.com
>>> 303-786-9961
>>>
>>>
>>>
>>> _______________________________________________
>>> Discuss mailing list
>>> Discuss at lists.osgeo.org
>>> http://lists.osgeo.org/mailman/listinfo/discuss
>>
>> _______________________________________________
>> Discuss mailing list
>> Discuss at lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/discuss
>>
>
>
>