[pgrouting-dev] Support for Time Constraints
Stephen Woodbridge
woodbri at swoodbridge.com
Mon Apr 4 12:59:47 EDT 2011
Jay,
You can sign up here for Navteq Network for Developers:
http://www.nn4d.com/site/global/home/p_home.jsp
This will allow you to download some sample data for a city like
Chicago, London, a few others.
Navteq has a very rich road network model that includes turn
restrictions and time dependent turn restrictions, road classification,
urban/rural and lots of other attributes to help you accurately model
the network. You can choose to incorporate as much as you see fit.
The time dependent feeds are typically called traffic feeds, if you are
googling for them, and provide near realtime speed information for major
roads in and around major cities. Typically they provide a Navteq
LINK_ID and a message about it, like the average speed, it a traffic
accident or lane closure and potentially volume of traffic. You can then
make some assumptions about the about time and speed. You might need
some queuing analysis to better understand the impact on traffic flow.
Regards,
-Steve
On 4/4/2011 12:07 PM, Jay Mahadeokar wrote:
> Hi,
>
> Since we will be working on time-dependent shortest path problem, I was
> wondering if time-dependent geographic data is freely available for
> research purposes. [1] states that we witness an increasing number of
> navigation service providers (such as Navteq and TeleAtlas) have started
> releasing their time-dependent travel-time datasets for road networks at
> high-resolution temporal granularity as fine as one sample for every
> five minutes.
>
> I guess that data is not freely available. Anyways, if you know such
> data-source can you please direct me? Besides this project, I am also
> working on some new heuristics for time-dependent shortest path as part
> of my thesis and the data would be really helpful for my work.
>
> Thanks.
>
> [1] http://portal.acm.org/citation.cfm?id=1869865
>
> On Thu, Mar 31, 2011 at 7:49 PM, Stephen Woodbridge
> <woodbri at swoodbridge.com <mailto:woodbri at swoodbridge.com>> wrote:
>
> 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
>
> _______________________________________________
> pgrouting-dev mailing list
> pgrouting-dev at lists.osgeo.org <mailto:pgrouting-dev at lists.osgeo.org>
> http://lists.osgeo.org/mailman/listinfo/pgrouting-dev
>
>
>
>
> --
> Regards,
> -Jay Mahadeokar
>
More information about the pgrouting-dev
mailing list