[pgrouting-dev] Support for Time Constraints

[Stephen Woodbridge]

On 3/30/2011 9:45 PM, Daniel Kastl wrote:

>
>             float cost := getEdgeCost(time, vehicle_type, node_from,
>         node_to);
>
>             or something like that. Where time could be NULL for some
>         default
>             behavior, or a value that would be used to figure out the cost.
>             vehicle_type might be helpful if there are multiple costs to
>             traverse a link based on say, car, carpool, bus, truck, walking,
>             taxi, etc. This could also be used to implement the rules
>         for bus
>             and train lines.
>
>
> I think one of the difficulties with routing topic is that everyone
> (also myself) immediately think about routing in terms of vehicle types.
> It's the easiest example to explain pgRouting, but I think one premise
> of pgRouting is that it should work for any kind of network. Let's say
> your network would be the human nervous system. What is a vehicle there?
> Well, probably changing "vehicle_type" to "speed" would make sense, right?

Sorry for using vehicle as the selector maybe "service_type" would be 
better, but the point is not the name, "speed" is equally misleading, 
the point is to be able to be able to pass a selector to the under lying 
function so that based on the selector we can compute an appropriate cost.

For my vehicle routing example, I chose: car, carpool, bus, truck, 
walking, taxi, etc. because these might have different rules associated 
to them. The selector values would be appropriate to the model that you 
were working with.

car vs carpool vs bus - many cities have HOV lanes that bus and carpool 
can use but not single occupancy cars. We might want to allocate a 
higher speed to those lanes vs the normal lanes during rush hours. 
Emergency vehicles many be allowed to make u-turns on highways that 
other vehicles can not make. Trucks might be banned from some streets so 
need to be costed appropriately, etc.

If we had a live traffic feed information linked to segment ids in 
another table, The cost function could be implemented to check that 
table and if a record exists then use that information or return the 
standard information. By keeping this data in a separate table that is 
presumably much smaller and dynamic than the street records it would 
make it much easier and more cost effective to make dynmaic changes to 
that table and to hide (abstract away complexity) by using a cost 
function supplied to the underlying code.

-Steve