[pgrouting-dev] Support for Time Constraints
Daniel Kastl
daniel at georepublic.de
Wed Jun 22 12:19:13 EDT 2011
Hi Jay,
You could once import OSM data with http://osm2po.de/
You can't configure the import of attributes as you do with osm2pgrouting,
but the created tables have a good set of attributes.
So you don't need to worry much about what Steve mentioned, that there are
no clear rules for setting attributes.
Daniel
2011/6/23 Stephen Woodbridge <woodbri at swoodbridge.com>
> Hi Jay,
>
> For now just push forward with what you have for testing that should be
> fine.
>
> In general, the OSM data has lots of options for classification, but it
> does not have clear standards or descriptions on how segments SHOULD be
> classified, so it is easy for different people to interpret the
> classifications differently. Hence, you end up with a huge list of segment
> classes like on:
>
>
> http://workshop.pgrouting.org/**chapters/advanced.html<http://workshop.pgrouting.org/chapters/advanced.html>
>
> with only short 1-2 word descriptions. So for example what is the
> difference between motorway, motorway_link, motorway_junction or for that
> matter a lane, opposite, opposite_lane, track, byway, circleway,
> living_street, residential, road, secondary, tertiary, track, roundabout and
> grade* types and how should these be represented as classes or for average
> speeds?
>
> In the link above they are trying to deal with this same issue by assigning
> a cost to the classes table based on the type name. They then use that cost
> as a multiplier of the length which is weird, but kind of works. This
> assumes the a cost multiplier of 2.0 means that that class takes 2X as long
> to traverse that segment as a class with a cost multiplier of 1.0.
>
> UPDATE classes SET cost=2.0 WHERE name IN ('pedestrian','steps','**
> footway');
>
> versus:
>
> UPDATE classes SET cost=0.3 WHERE name IN ('motorway','motorway_**
> junction','motorway_link');
>
> and in these segments vehicle speed is faster to the cost is smaller.
>
> I take a more intuitive approach to this problem, by assigning an average
> speed for each class of segment, then length / average speed represents the
> average traversal time. So it is easy to make adjustments to the model and
> you can easily do shortest time or distance.
>
> -Steve
>
>
> On 6/22/2011 10:42 AM, Jay Mahadeokar wrote:
>
>>
>>
>> On Wed, Jun 22, 2011 at 7:57 PM, Stephen Woodbridge
>> <woodbri at swoodbridge.com <mailto:woodbri at swoodbridge.**com<woodbri at swoodbridge.com>>>
>> wrote:
>>
>> Hi Jay,
>>
>> I am back from my trip and wading through emails.
>>
>> I am interested in what your rationale for looking a length as a
>> classifier is. It would seem to me the length of a given segment has
>> nothing to do with classifying a segment with respect to speed or
>> road class. The length of a segment is typically a function of how
>> often that route is intersected by other features. For example and a
>> path through a city will have more intersections than a path through
>> a rural country side. A mountain pass could be a very long segment
>> but might be a very slow path because it is twisty and has a lot of
>> elevation changes. A major road through a city might have
>> intersections at every block hence have short segments but could
>> still move a lot of traffic from one side of the city to another.
>>
>> For testing purposes, any random classification is fine, but I like
>> to pick classifications the reasonably model real life so when I see
>> the results they reflect some general cognitive expectations and I
>> can understand then or detect anomalies which might indicat a bug in
>> the algorithm.
>>
>>
>> Maybe I am missing the point, anyway just trying to understand and
>> not suggesting that you change anything at this point.
>>
>>
>> Hi Steve,
>>
>> Well I was very confused regarding the classification too since I have
>> zero experience with real world data, and so I just choose length as
>> criteria. This data is just for test purpose. We can modify the model
>> and criteria any time, since writing the plsql procedure to generate
>> such does not take too much effort. Also, the data does not affect the
>> internal working of the algorithm, so I think for now, I can work with
>> the currently generated test data.
>>
>> Any other ideas/ criteria for classification are welcome, and I would
>> write the scripts to generate corresponding data.
>>
>>
>> -Steve
>>
>>
>> On 6/17/2011 12:42 AM, Jay Mahadeokar wrote:
>>
>> Hi,
>>
>> Here is an interesting look into the data in ways table:
>>
>> pgrouting-workshop=# select round(avg(length)*10000) as avg,
>> round(min(length)*10000) as min, round(max(length)*10000) as
>> max,count(*) as count, class_id from ways group by class_id
>> order by avg
>> desc;
>>
>> avg | min | max | count | class_id
>> ------+------+-------+-------+ ----------
>> 5320 | 250 | 12163 | 21 | 101
>> 2135 | 1885 | 2385 | 2 | 111
>> 1970 | 396 | 5168 | 17 | 102
>> 1343 | 10 | 27485 | 234 | 106
>> 1115 | 33 | 7964 | 221 | 108
>> 1037 | 14 | 20020 | 248 | 109
>> 938 | 9 | 23142 | 2761 | 110
>> 837 | 21 | 2212 | 43 | 100
>> 626 | 8 | 3327 | 90 | 112
>> 619 | 26 | 9089 | 252 | 119
>> 486 | 123 | 1618 | 11 | 117
>> 473 | 7 | 16582 | 1259 | 114
>> 364 | 97 | 1578 | 45 | 122
>> 260 | 4 | 718 | 109 | 401
>> (14 rows)
>>
>> So, I am going by the average length figure and considering
>> class_id =
>> (1001,111,102) as Type I (major_highways), which will be
>> affected most
>> by the traffic.
>>
>> class_id = (106,108,109,110,100) as Type II (minor_highways)
>> which be
>> comparatively less populated.
>>
>> class_id = (112,119,117,114,122,401) as Type III (streets) which
>> will
>> have least traffic.
>>
>> We want to have model such that during traffic hours the
>> shortest path
>> should go through streets.
>>
>> So, I am dividing day into following intervals, hope it sounds
>> reasonable. I will write the corresponding plsql function that will
>> generate the data accordingly. Note that the speed is in
>> percentage of
>> average speed. Since, we want to deal with time, we can effectively
>> increase the lengths of the edges by same factor and assume speed
>> as
>> constant.
>>
>>
>> Time Interval Speed for Type I Speed for Type II
>> Speed for Type III
>>
>>
>>
>>
>> 10 PM – 6 AM 100 100 100
>> 6 AM – 7 AM 95 90 100
>> 7 AM – 8 AM 80 75 90
>> 8 AM – 9 AM 50 45 85
>> 9 AM – 10 AM 60 55 85
>> 10 AM – 11 AM 90 85 95
>> 11 AM – 5 PM 100 100 100
>> 5 PM – 6 PM 90 85 95
>> 6 PM – 7 PM 75 70 90
>> 7 PM – 8 PM 50 45 85
>> 8 PM – 9 PM 60 55 85
>> 9 PM – 10 PM
>> 95 90 95
>>
>>
>>
>> Any feedback is welcome.
>>
>> I am currently stuck with a bug in the core time-dependent
>> function,
>> there seems to be a problem with non-integer data. Will try and
>> fix that
>> soon.
>>
>>
>> On Wed, Jun 15, 2011 at 7:26 AM, Jay Mahadeokar
>> <jai.mahadeokar at gmail.com <mailto:jai.mahadeokar at gmail.**com<jai.mahadeokar at gmail.com>
>> >
>> <mailto:jai.mahadeokar at gmail. com
>> <mailto:jai.mahadeokar at gmail.**com <jai.mahadeokar at gmail.com>>>>
>> wrote:
>>
>>
>>
>> On Sun, Jun 12, 2011 at 8:00 PM, Stephen Woodbridge
>> <woodbri at swoodbridge.com <mailto:woodbri at swoodbridge.**com<woodbri at swoodbridge.com>
>> >
>> <mailto:woodbri at swoodbridge. com
>>
>> <mailto:woodbri at swoodbridge.**com <woodbri at swoodbridge.com>>>>
>> wrote:
>>
>> Jay,
>>
>> Try:
>>
>> select class_id, count(*) as cnt from ways group by
>> class_id
>> oder by classid;
>>
>> Typically you should a a distribution in real world data
>> something like:
>>
>> 5% limited access major highways
>> 15% major roads
>> 75% minor roads
>> 5% trails, pedestrian ways, etc
>>
>>
>> Hi,
>>
>> We have got following data in the pgrouting-workshop ways
>> table.
>>
>> pgrouting-workshop=# select distinct(count(class_id)) as
>> no_of_entries,class_id from ways group by class_id order by
>> no_of_entries;
>> no_of_entries | class_id
>> ---------------+----------
>> 2 | 111
>> 11 | 117
>> 17 | 102
>> 21 | 101
>> 43 | 100
>> 45 | 122
>> 90 | 112
>> 109 | 401
>> 221 | 108
>> 234 | 106
>> 248 | 109
>> 252 | 119
>> 1259 | 114
>> 2761 | 110
>> (14 rows)
>>
>>
>> The classes table in routing database gives more information
>> on the
>> class_id field. Also available here:
>> http://workshop.pgrouting.org/ chapters/advanced.html
>> <http://workshop.pgrouting.**org/chapters/advanced.html<http://workshop.pgrouting.org/chapters/advanced.html>
>> >
>>
>> So, we have:
>>
>> class_id name no_of_entries
>>
>> 110 track 2761
>> 114 path 1259
>> 119 steps 252
>> 109 service 248
>> 106 primary 234
>> 108 living_street 221
>> 401 roundabout 109
>>
>> These are the major class_types with more than 100 entries
>> in ways
>> table.
>>
>> Steve had earlier suggested following idea for time
>> dependent data
>> generation:
>>
>>
>> "If we think about "rush hour" around a major city, the highways
>> (based on road class) flowing into the city in the morning
>> would get
>> reduced average speeds you could apply curve like average
>> speed*percent based on 6am (90%), 7am(75%), 8am(45%), 9am(50%),
>> 10am(85%) and do something similar in the evening rush. It
>> might be
>> too hard to figure on direction of flow in/out bound so
>> apply the
>> curve to all traffic. The assumption is that the highways are
>> congested which will force traffic onto side streets. You
>> might want
>> to also reduce the lower class speeds by say a constant 80%
>> during
>> rush hour."
>>
>> So, what classes should I consider as highways, what classes as
>> streets and so on? Or What should be the pattern of speed
>> changes in
>> various classes?
>>
>> The main focus would be, we should be routed through less
>> congested
>> areas during rush hours right?
>>
>> Once we finalise this model, I can write the plsql function to
>> generate the corresponding data.
>>
>>
>>
>> Well in the US anyway. Also if this is OSM data then you
>> might
>> get a better clue on classes by looking to that ....
>> OH!, look
>> what I found in google :)
>>
>> http://workshop.pgrouting.org/ chapters/advanced.html
>> <http://workshop.pgrouting.**org/chapters/advanced.html<http://workshop.pgrouting.org/chapters/advanced.html>
>> >
>>
>> Looks like first digit is type and the three digits are
>> from the
>> classes table.
>>
>> -Steve
>>
>>
>> On 6/12/2011 4:33 AM, Jay Mahadeokar wrote:
>>
>>
>>
>> On Sun, Jun 12, 2011 at 1:32 PM, Anton Patrushev
>> <anton.patrushev at georepublic. de
>> <mailto:anton.patrushev@**georepublic.de<anton.patrushev at georepublic.de>
>> >
>> <mailto:anton.patrushev@ georepublic.de
>> <mailto:anton.patrushev@**georepublic.de<anton.patrushev at georepublic.de>
>> >>
>> <mailto:anton.patrushev@ georepublic.de
>> <mailto:anton.patrushev@**georepublic.de<anton.patrushev at georepublic.de>
>> >
>> <mailto:anton.patrushev@ georepublic.de
>> <mailto:anton.patrushev@**georepublic.de<anton.patrushev at georepublic.de>
>> >>>>
>>
>> wrote:
>>
>> Hi Jay,
>>
>> No, there was no specific meaning, just king of
>> cyphering - first
>> digit for road class and then two last digits
>> for road type.
>>
>>
>> Hi Anton,
>>
>> So, as you said last 2 digits are for road type. I
>> can see
>> they are
>> mainly 00, 01, 02, 06, 08, 09, 10, 11, 12 ,14, 17.
>>
>> Road class is just 1 or 4.
>>
>> Can I differentiate major highways, minor highways,
>> streets
>> etc using
>> this info?
>>
>> Anton.
>>
>> On 6/12/11, Jay Mahadeokar
>> <jai.mahadeokar at gmail.com <mailto:jai.mahadeokar at gmail.**com<jai.mahadeokar at gmail.com>
>> >
>> <mailto:jai.mahadeokar at gmail. com <mailto:jai.mahadeokar at gmail.**
>> com <jai.mahadeokar at gmail.com>>>
>> <mailto:jai.mahadeokar at gmail. com <mailto:jai.mahadeokar at gmail.**
>> com <jai.mahadeokar at gmail.com>>
>> <mailto:jai.mahadeokar at gmail. com
>> <mailto:jai.mahadeokar at gmail.**com <jai.mahadeokar at gmail.com>>>>>
>> wrote:
>> >> Hi Jay,
>> >>
>> >> I think that instead of just random times, I would take
>> a different
>> >> approach to generate this data. If we think about "rush
>> hour"
>> around a
>> >> major
>> >> city, the highways (based on road class) flowing into
>> the city
>> in the
>> >> morning would get reduced average speeds you could apply
>> curve like
>> >> average
>> >> speed*percent based on 6am (90%), 7am(75%), 8am(45%),
>> 9am(50%),
>> 10am(85%)
>> >> and do something similar in the evening rush. It might
>> be too
>> hard to
>> >> figure
>> >> on direction of flow in/out bound so apply the curve to all
>> traffic. The
>> >> assumption is that the highways are congested which will
>> force
>> traffic
>> >> onto
>> >> side streets. You might want to also reduce the lower class
>> speeds by say
>> >> a
>> >> constant 80% during rush hour.
>> >>
>> >> If we can get OSM data then it should be easy to
>> populate the
>> table with
>> >> that data.
>> >>
>> >> -Steve
>> >>
>> >
>> > I am trying to write plpgsql query to generate
>> time-dependent data
>> > corresponding to the ways table in pgrouting workshop. As
>> suggested by Steve
>> > above, instead of generating random data, I will follow
>> patterns
>> (see above
>> > message) so that the data is nearer to the real worlds
>> scenario.
>> >
>> > So, now I need to make distinction between highways,
>> streets etc.
>> I saw the
>> > attribute class_id in ways table. It has 14 distinct values:
>> > class_id
>> >
>> > ----------
>> >
>> >
>> > 102
>> >
>> >
>> > 122
>> >
>> >
>> > 106
>> >
>> >
>> > 111
>> >
>> >
>> > 108
>> >
>> >
>> > 100
>> >
>> >
>> > 109
>> >
>> >
>> > 112
>> >
>> >
>> > 101
>> >
>> >
>> > 110
>> >
>> >
>> > 401
>> >
>> >
>> > 119
>> >
>> >
>> > 117
>> >
>> > 114
>> >
>> > Any specific meaning attached to these values? I did not
>> find any
>> > information on the pgRouting-workshop website [1].
>> >
>> >
>> > Thanks in advance.
>> >
>> > [1] http://workshop.pgrouting.org/ chapters/topology.html
>> <http://workshop.pgrouting.**org/chapters/topology.html<http://workshop.pgrouting.org/chapters/topology.html>
>> >
>> >
>> > --
>> > Regards,
>> > -Jay Mahadeokar
>> >
>>
>>
>> --
>> Georepublic UG (haftungsbeschränkt)
>> Salzmannstraße 44,
>> 81739 München, Germany
>>
>> Anton Patrushev
>> CTO
>>
>> eMail: anton.patrushev at georepublic.de
>> <mailto:anton.patrushev@**georepublic.de<anton.patrushev at georepublic.de>
>> >
>> <mailto:anton.patrushev@ georepublic.de
>> <mailto:anton.patrushev@**georepublic.de<anton.patrushev at georepublic.de>
>> >>
>> <mailto:anton.patrushev@ georepublic.de
>> <mailto:anton.patrushev@**georepublic.de<anton.patrushev at georepublic.de>
>> >
>> <mailto:anton.patrushev@ georepublic.de
>> <mailto:anton.patrushev@**georepublic.de<anton.patrushev at georepublic.de>
>> >>>
>>
>> Web: http://georepublic.de
>>
>> Tel: +49 (089) 420 959 519
>> Sip: 1959519 at sipgate.de
>> <mailto:1959519 at sipgate.de> <mailto:1959519 at sipgate.de
>> <mailto:1959519 at sipgate.de>>
>> <mailto:1959519 at sipgate.de <mailto:1959519 at sipgate.de>
>> <mailto:1959519 at sipgate.de <mailto:1959519 at sipgate.de>>>
>>
>>
>>
>> Commercial register: Amtsgericht München, HRB
>> 181428
>> CEO: Daniel Kastl
>> ______________________________ _________________
>> pgrouting-dev mailing list
>> pgrouting-dev at lists.osgeo.org <mailto:pgrouting-dev at lists.**
>> osgeo.org <pgrouting-dev at lists.osgeo.org>>
>> <mailto:pgrouting-dev at lists. osgeo.org
>> <mailto:pgrouting-dev at lists.**osgeo.org<pgrouting-dev at lists.osgeo.org>
>> >>
>> <mailto:pgrouting-dev at lists. osgeo.org
>> <mailto:pgrouting-dev at lists.**osgeo.org<pgrouting-dev at lists.osgeo.org>
>> >
>> <mailto:pgrouting-dev at lists. osgeo.org
>> <mailto:pgrouting-dev at lists.**osgeo.org<pgrouting-dev at lists.osgeo.org>
>> >>>
>>
>> http://lists.osgeo.org/ mailman/listinfo/pgrouting-dev
>> <http://lists.osgeo.org/**mailman/listinfo/pgrouting-dev<http://lists.osgeo.org/mailman/listinfo/pgrouting-dev>
>> **>
>>
>>
>>
>>
>> --
>> Regards,
>> -Jay Mahadeokar
>>
>>
>>
>> ______________________________ _________________
>> pgrouting-dev mailing list
>> pgrouting-dev at lists.osgeo.org <mailto:pgrouting-dev at lists.**
>> osgeo.org <pgrouting-dev at lists.osgeo.org>>
>> <mailto:pgrouting-dev at lists. osgeo.org
>> <mailto:pgrouting-dev at lists.**osgeo.org<pgrouting-dev at lists.osgeo.org>
>> >>
>> http://lists.osgeo.org/ mailman/listinfo/pgrouting-dev
>> <http://lists.osgeo.org/**mailman/listinfo/pgrouting-dev<http://lists.osgeo.org/mailman/listinfo/pgrouting-dev>
>> **>
>>
>>
>> ______________________________ _________________
>> pgrouting-dev mailing list
>> pgrouting-dev at lists.osgeo.org
>> <mailto:pgrouting-dev at lists.**osgeo.org<pgrouting-dev at lists.osgeo.org>
>> >
>> <mailto:pgrouting-dev at lists. osgeo.org
>> <mailto:pgrouting-dev at lists.**osgeo.org<pgrouting-dev at lists.osgeo.org>
>> >>
>> http://lists.osgeo.org/ mailman/listinfo/pgrouting-dev
>> <http://lists.osgeo.org/**mailman/listinfo/pgrouting-dev<http://lists.osgeo.org/mailman/listinfo/pgrouting-dev>
>> **>
>>
>>
>>
>>
>> --
>> Regards,
>> -Jay Mahadeokar
>>
>>
>>
>>
>> --
>> Regards,
>> -Jay Mahadeokar
>>
>>
>>
>> ______________________________ _________________
>> pgrouting-dev mailing list
>> pgrouting-dev at lists.osgeo.org <mailto:pgrouting-dev at lists.**
>> osgeo.org <pgrouting-dev at lists.osgeo.org>>
>>
>> http://lists.osgeo.org/ mailman/listinfo/pgrouting-dev
>> <http://lists.osgeo.org/**mailman/listinfo/pgrouting-dev<http://lists.osgeo.org/mailman/listinfo/pgrouting-dev>
>> **>
>>
>>
>> ______________________________ _________________
>> pgrouting-dev mailing list
>> pgrouting-dev at lists.osgeo.org <mailto:pgrouting-dev at lists.**osgeo.org<pgrouting-dev at lists.osgeo.org>
>> >
>> http://lists.osgeo.org/ mailman/listinfo/pgrouting-dev
>> <http://lists.osgeo.org/**mailman/listinfo/pgrouting-dev<http://lists.osgeo.org/mailman/listinfo/pgrouting-dev>
>> **>
>>
>>
>>
>>
>> --
>> Regards,
>> -Jay Mahadeokar
>>
>>
>>
>> ______________________________**_________________
>> pgrouting-dev mailing list
>> pgrouting-dev at lists.osgeo.org
>> http://lists.osgeo.org/**mailman/listinfo/pgrouting-dev<http://lists.osgeo.org/mailman/listinfo/pgrouting-dev>
>>
>
> ______________________________**_________________
> pgrouting-dev mailing list
> pgrouting-dev at lists.osgeo.org
> http://lists.osgeo.org/**mailman/listinfo/pgrouting-dev<http://lists.osgeo.org/mailman/listinfo/pgrouting-dev>
>
--
Georepublic UG & Georepublic Japan
eMail: daniel.kastl at georepublic.de
Web: http://georepublic.de
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/pgrouting-dev/attachments/20110623/ce2d999a/attachment-0001.html
More information about the pgrouting-dev
mailing list