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

Tue Sep 14 11:20:48 PDT 2010

On reflection, viewshed analysis might be used for route choice if for example one might want the view of something on a route (this could be something relatively precisely located e.g. the tip of the Eiffel Tower, or something imprecisely located e.g. the sea). Elevation and landcover and details of season etc may well come into such a calculation...

________________________________________
From: discuss-bounces at lists.osgeo.org [discuss-bounces at lists.osgeo.org] On Behalf Of Andy Turner [A.G.D.Turner at leeds.ac.uk]
Sent: 14 September 2010 18:53
To: discuss at lists.osgeo.org
Cc: Stephen Carver; Justin Washtell
Subject: RE: [OSGeo-Discuss] Thoughts on how to use elevation in routing

Hi OSGeo Discussions, (cc Steve, Justin),

In terms of the computing of viewsheds, both Steve Carver (http://www.geog.leeds.ac.uk/people/s.carver/) and Justin Washtell (http://www.comp.leeds.ac.uk/washtell/) have done some work on this, but I don't know the latest...

It can be useful to compute which bits of road can be seen from other bits of road and what impact roads have on the perception of wilderness from off the road. Same true with vehicles on roads although these are usually moving.

I think the viewshed work though is somewhat orthogonal to including elevation in routing application outwith surveillance and visual impact contexts.

One further thought: it is much nicer to have junctions (where traffic is to slow and potentially stop for ordered inetrsection) well laid out at the top of small hills. This is for network flow and general economy and safety reasons. So in the analysis of a route, some quantification of junction impact taking into account elevation might be good.

HTH

Andy
http://www.geog.leeds.ac.uk/people/a.turner/

-----Original Message-----
From: discuss-bounces at lists.osgeo.org [mailto:discuss-bounces at lists.osgeo.org] On Behalf Of Stephen Woodbridge
Sent: 14 September 2010 17:31
To: discuss at lists.osgeo.org
Subject: Re: [OSGeo-Discuss] Thoughts on how to use elevation in routing

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
_______________________________________________
Discuss mailing list
Discuss at lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/discuss