<html dir="ltr"><head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<style type="text/css">BODY {
LINE-HEIGHT: normal; FONT-VARIANT: normal; MARGIN: 4px 4px 1px
}
P {
MARGIN-TOP: 0px; MARGIN-BOTTOM: 0px
}
</style>
<meta name="GENERATOR" content="MSHTML 8.00.6001.18939">
<style id="owaTempEditStyle"></style><style title="owaParaStyle"><!--P {
MARGIN-TOP: 0px; MARGIN-BOTTOM: 0px
}
--></style>
<meta name="SKYPE_FRAMEID" content="VFPEUAGBSX">
</head>
<body style="MARGIN: 4px 4px 1px" ocsi="x">
<div style="FONT-FAMILY: Tahoma; DIRECTION: ltr; COLOR: #000000; FONT-SIZE: 13px">
<div>Hi All</div>
<div><font size="2" face="tahoma">I seem to remember reading somewhere that UPS delivery routes are constructed with only right turns (or left depending on the country) so as to make use of 'free' turns to avoid waiting at traffic lights.
</font></div>
<div><font size="2" face="tahoma">Geoff</font></div>
<div dir="ltr"><font color="#000000" size="2" face="Tahoma"></font> </div>
<div style="DIRECTION: ltr" id="divRpF319408">
<hr tabindex="-1">
<font color="#000000" size="2" face="Tahoma"><b>From:</b> discuss-bounces@lists.osgeo.org [discuss-bounces@lists.osgeo.org] On Behalf Of Bob Basques [Bob.Basques@ci.stpaul.mn.us]<br>
<b>Sent:</b> Wednesday, 15 September 2010 6:26 a.m.<br>
<b>To:</b> discuss@lists.osgeo.org<br>
<b>Cc:</b> Stephen Carver; Justin Washtell<br>
<b>Subject:</b> RE: [OSGeo-Discuss] Thoughts on how to use elevation in routing<br>
</font><br>
</div>
<div></div>
<div>
<p style="MARGIN-TOP: 0px; MARGIN-BOTTOM: 0px"><font size="3" face="Comic Sans MS">All,</font>
</p>
<br>
<p style="MARGIN-TOP: 0px; MARGIN-BOTTOM: 0px"><font size="3" face="Comic Sans MS">The view of road, got me thinking about auto-placement of bridges and their locations, and even what road is above what other road. While not being able to tell exactly how
long a bridge might be, it would be usefull for locating (and styling) a bridge location along a roadway, at least down to all but the highest level of resolution.</font>
</p>
<br>
<p style="MARGIN-TOP: 0px; MARGIN-BOTTOM: 0px"><font size="3" face="Comic Sans MS">Might also be a tunnel extraction method here with the right sort of DEM available.</font>
</p>
<br>
<p style="MARGIN-TOP: 0px; MARGIN-BOTTOM: 0px"><font size="3" face="Comic Sans MS">I also just thought of a question, in a high resolution environment (I have one foot contours/DEM data for our City), it might be beneficial to describe the line along it's length
in some manner, where breaks in elevation occur, etc. Country and rural roads might not have breaks in them for some measure of distance, but have many vertical undulations along the space horizontal distance.</font>
</p>
<br>
<p style="MARGIN-TOP: 0px; MARGIN-BOTTOM: 0px"><font size="3" face="Comic Sans MS">bobb</font>
</p>
<br>
<p style="MARGIN-TOP: 0px; MARGIN-BOTTOM: 0px"><br>
<br>
>>> Andy Turner <A.G.D.Turner@leeds.ac.uk> wrote:<br>
</p>
<div style="BORDER-LEFT: #050505 1px solid; BACKGROUND-COLOR: #f3f3f3; MARGIN: 0px 0px 0px 15px; PADDING-LEFT: 7px">
<p style="MARGIN-TOP: 0px; MARGIN-BOTTOM: 0px">Hi OSGeo Discussions, (cc Steve, Justin),<br>
<br>
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...<br>
<br>
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.<br>
<br>
I think the viewshed work though is somewhat orthogonal to including elevation in routing application outwith surveillance and visual impact contexts.<br>
<br>
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.<br>
<br>
HTH<br>
<br>
Andy<br>
<a href="http://www.geog.leeds.ac.uk/people/a.turner/" target="_blank">http://www.geog.leeds.ac.uk/people/a.turner/</a><br>
<br>
<br>
-----Original Message-----<br>
From: discuss-bounces@lists.osgeo.org [mailto:discuss-bounces@lists.osgeo.org] On Behalf Of Stephen Woodbridge<br>
Sent: 14 September 2010 17:31<br>
To: discuss@lists.osgeo.org<br>
Subject: Re: [OSGeo-Discuss] Thoughts on how to use elevation in routing<br>
<br>
On 9/14/2010 11:43 AM, Bill Thoen wrote:<br>
> Steve,<br>
><br>
> Adding viewsheds to the package would certainly up the computing costs;<br>
> I was wondering if you had a limit to what sort of processing power<br>
> you've got there. ;-)<br>
<br>
It is not unlimited, so part of the problem that is interesting to me is<br>
how to find and compute economical way to do it.<br>
<br>
> I also think what you're proposing might be interesting, but you have to<br>
> be careful about what conclusions you can draw from it. At what point<br>
> does the cost due to gradient variations become insignificant to the<br>
> overall cost of a route for a particular type of vehicle? For a trucker<br>
> on an interstate highway it doesn't signify because the statistical<br>
> noise of factors such high speeds and short driving time balanced<br>
> against the higher price of fuel, services and road freight taxes<br>
> completely overwhelms the cost factor contributed by the change in<br>
> gradients. So in those cases you'd be computing numbers but not saying<br>
> anything.<br>
<br>
Agreed, doing anything for the trucking industry that would be useful<br>
probably requires a lot more understanding of the industry and<br>
regulations required for that. Luckily it is not my main focus :)<br>
<br>
> A different scenario, where gradient /is/ a significant factor, would be<br>
> a three-day 100 mile bike ride event through the mountains (like the<br>
> 'Ride the Rockies' event they hold around here every year.) The power<br>
> that bicyclists can produce is so low that speeds and endurance are<br>
> strongly affected by grades. But a bicyclist doesn't typically operate<br>
> on the scale of the nation so applying the calculations to the entire<br>
> TIGER file is overkill. Also, the bicyclist operates on such a large<br>
> scale that the source data you're using to calculate gradient (30m DEM)<br>
> may be too coarse to be reliable on the bicyclist's scale.<br>
<br>
Right, these points are all valid and have crossed my mind at one point<br>
or another. Applying this to the Tiger data set is not that big of a<br>
deal. I already have the Tiger data in XYZ so computing grades is not<br>
that difficult. Another reason for applying it to the whole data set is<br>
to build a web portal with US coverage. Granted any single route will<br>
not have continental scope, but individual routes might be anywhere on<br>
the continent.<br>
<br>
> I'm not saying it isn't worth doing, I'm just saying you'll need to<br>
> qualify the precision of your results before you can say much about<br>
> applying this to any real-world problems.<br>
<br>
I'll post a link back if I get anything working. Meanwhile, thanks for<br>
the ideas and thoughts.<br>
<br>
-Steve<br>
<br>
> - Bill Thoen<br>
><br>
><br>
> On 9/13/2010 5:28 PM, Stephen Woodbridge wrote:<br>
>> Bill,<br>
>><br>
>> Thanks for the ideas. I might try to do something with the viewshed<br>
>> idea in the future. It would need a LOT of computing to process all<br>
>> the road segments in a National dataset like Tiger.<br>
>><br>
>> But for now I would like to figure out the routing costs.<br>
>><br>
>> One idea I had was to compute the grade for a segment and then compute<br>
>> cost as:<br>
>><br>
>> cost = (time or distance) * scalefactor * max(abs(grade), 1.0)<br>
>><br>
>> This would have the effect of causing segments with a lot of grade to<br>
>> have a higher cost of traversal.<br>
>><br>
>> Or similarly, if you want to pick roads with a lot of elevation<br>
>> changes then use cost factor like:<br>
>><br>
>> cost = (time or distance) * scalefactor /<br>
>> abs(sum_elevation_changes_over_the_segment)<br>
>><br>
>> This would have the effect of decreasing the traversal cost for<br>
>> segments that have a lot of elevation changes.<br>
>><br>
>> These are pretty crude estimates and probably would need some fine<br>
>> tuning to get reasonable results.<br>
>><br>
>> Thanks,<br>
>> -Steve W<br>
>><br>
>> On 9/13/2010 4:24 PM, Bill Thoen wrote:<br>
>>> Stephen Woodbridge wrote:<br>
>>>> Hi all,<br>
>>>><br>
>>>> (This is cross posting from the pgrouting list, sorry for the dups.)<br>
>>>><br>
>>>> I have preprocessed some shapefile data and added elevation<br>
>>>> information in the Z value of the coordinates. I'm wondering how to<br>
>>>> best utilize that in routes and would like any thoughts or ideas you<br>
>>>> might be willing to share.<br>
>>>><br>
>>>> The obvious answer is to wrap the elevation data into the cost values<br>
>>>> as this is simple and straight forward and does not require code<br>
>>>> changes. This brings me to what have other people done or thought<br>
>>>> about doing in this regard?<br>
>>> Since you seem to enjoy large database problems, have you considered<br>
>>> loading the DEM data together with the roads and sample the viewshed<br>
>>> every few km? You could then create an objective cost factor for<br>
>>> "scenic," proportional to the amount of land visible, with some<br>
>>> adjusting factor that distinguishes morphology, land cover, or other<br>
>>> weighted factors from each sample point. Creating a scale of "scenic"<br>
>>> and "picturesque" as it goes form "ho-hum flatland" to "precipitous,<br>
>>> brake-burning, wheel-gripping adventurous" might be fun all by itself.<br>
>>><br>
>>> If you're looking for 3D ideas, there's a GIS consulting company across<br>
>>> the hall from me that specializes in 3D information, visualization and<br>
>>> analysis, and I know they are working on web services to deliver the<br>
>>> sort of data that an application like yours would consume. Their website<br>
>>> is full of 3D imagery, articles and examples that you might want to<br>
>>> check out for ideas or inspiration There's a particularly good<br>
>>> demonstration of using fog instead of shadow to create a visual<br>
>>> representation of ridge lines, if your 're using those to determine a<br>
>>> topographic index (see <a href="http://ctmap.com/serendipity/index.php)." target="_blank">
http://ctmap.com/serendipity/index.php).</a><br>
>>><br>
>>> *Bill Thoen*<br>
>>> GISnet - www.gisnet.com <<a href="http://www.gisnet.com/" target="_blank">http://www.gisnet.com/</a>><br>
>>> 1401 Walnut St., Suite C<br>
>>> Boulder, CO 80302<br>
>>> 303-786-9961 tel<br>
>>> 303-443-4856 fax<br>
>>> bthoen@gisnet.com<br>
>>><br>
>>> _______________________________________________<br>
>>> Discuss mailing list<br>
>>> Discuss@lists.osgeo.org<br>
>>> <a href="http://lists.osgeo.org/mailman/listinfo/discuss" target="_blank">http://lists.osgeo.org/mailman/listinfo/discuss</a><br>
>><br>
>> _______________________________________________<br>
>> Discuss mailing list<br>
>> Discuss@lists.osgeo.org<br>
>> <a href="http://lists.osgeo.org/mailman/listinfo/discuss" target="_blank">http://lists.osgeo.org/mailman/listinfo/discuss</a><br>
>><br>
><br>
> --<br>
> *Bill Thoen*<br>
> GISnet - www.gisnet.com<br>
> 303-786-9961<br>
><br>
><br>
><br>
> _______________________________________________<br>
> Discuss mailing list<br>
> Discuss@lists.osgeo.org<br>
> <a href="http://lists.osgeo.org/mailman/listinfo/discuss" target="_blank">http://lists.osgeo.org/mailman/listinfo/discuss</a><br>
<br>
_______________________________________________<br>
Discuss mailing list<br>
Discuss@lists.osgeo.org<br>
<a href="http://lists.osgeo.org/mailman/listinfo/discuss" target="_blank">http://lists.osgeo.org/mailman/listinfo/discuss</a><br>
_______________________________________________<br>
Discuss mailing list<br>
Discuss@lists.osgeo.org<br>
<a href="http://lists.osgeo.org/mailman/listinfo/discuss" target="_blank">http://lists.osgeo.org/mailman/listinfo/discuss</a><br>
</p>
</div>
</div>
</div>
</body>
</html>