<html>
<head>
<style type="text/css">
<!--
body { margin-left: 4px; margin-right: 4px; margin-top: 4px; margin-bottom: 1px; line-height: normal; font-variant: normal }
p { margin-top: 0; margin-bottom: 0 }
-->
</style>
</head>
<body style="margin-left: 4px; margin-right: 4px; margin-top: 4px; margin-bottom: 1px">
<p style="margin-bottom: 0; margin-top: 0">
<font size="3" face="Comic Sans MS">All,</font> </p>
<br>
<p style="margin-bottom: 0; margin-top: 0">
<font size="3" face="Comic Sans MS">One thought just occurred to me related to this thread, what would street construction type add to the equation? Dirt/gravel/blacktop/concrete, add on to that age of road/ADT and roughness might start becoming a factor as well. I know these are getting a bit right or left of the original question, but if the data is available . . .</font> </p>
<br>
<p style="margin-bottom: 0; margin-top: 0">
<font size="3" face="Comic Sans MS">Might be able to auto extract such things from high resolution photography, also spectral photogrphy is also a viable tool here.</font> </p>
<br>
<p style="margin-bottom: 0; margin-top: 0">
<font size="3" face="Comic Sans MS">bobb</font> </p>
<br>
<p style="margin-bottom: 0; margin-top: 0">
<br>
<br>
>>> Stephen Woodbridge <woodbri@swoodbridge.com> wrote:<br> </p>
<div style="margin-left: 15px; margin-right: 0; margin-top: 0; background-color: #f3f3f3; margin-bottom: 0; border-left: solid 1px #050505; padding-left: 7px">
<p style="margin-bottom: 0; margin-top: 0">
Yes, this is another good factor to look at. Curvature can be computed<br>as the 2nd derivative or the rate of change in angle along the road.<br>This is a little harder to compute with segments as you need to join<br>adjacent segments to compute this or you get disconnects where they<br>join. And you have to figure out what are "through" streets at<br>intersections of more then two segments. But still a good measure.<br><br>Also "curvyness" can often com into play when following rivers and<br>streams even when there is not significant grade.<br><br>-Steve<br><br>On 9/14/2010 12:52 PM, Richard Greenwood wrote:<br>> I think "cruvyness" might also be a useful resistance factor, and it<br>> is often associated with grade, as in steep mountain roads with lots<br>> of switchbacks. After attending FOSS4G last week my wife and I have<br>> been driving and biking in the Pyrenees and experiencing the effects<br>> of both cruvyness and grade on our travel times.<br>><br>> Rich<br>><br>> On Tue, Sep 14, 2010 at 10:31 AM, Stephen Woodbridge<br>> <woodbri@swoodbridge.com> wrote:<br>>> On 9/14/2010 11:43 AM, Bill Thoen wrote:<br>>>><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 how<br>>> 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 regulations<br>>> 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 or<br>>> another. Applying this to the Tiger data set is not that big of a deal. I<br>>> already have the Tiger data in XYZ so computing grades is not that<br>>> difficult. Another reason for applying it to the whole data set is to build<br>>> a web portal with US coverage. Granted any single route will not have<br>>> continental scope, but individual routes might be anywhere on 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 the<br>>> ideas and thoughts.<br>>><br>>> -Steve<br>>><br>>>> - Bill Thoen<br>>>><br>>>><br>>>> On 9/13/2010 5:28 PM, Stephen Woodbridge wrote:<br>>>>><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>>>>>><br>>>>>> Stephen Woodbridge wrote:<br>>>>>>><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>>>>>><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).">http://ctmap.com/serendipity/index.php).</a><br>>>>>><br>>>>>> *Bill Thoen*<br>>>>>> GISnet - www.gisnet.com<<a href="http://www.gisnet.com/">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">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">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">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">http://lists.osgeo.org/mailman/listinfo/discuss</a><br>>><br>><br>><br>><br><br>_______________________________________________<br>Discuss mailing list<br>Discuss@lists.osgeo.org<br><a href="http://lists.osgeo.org/mailman/listinfo/discuss">http://lists.osgeo.org/mailman/listinfo/discuss</a><br>
</p>
</div>
</body>
</html>