[pgrouting-dev] Support for Time Constraints
Stephen Woodbridge
woodbri at swoodbridge.com
Fri May 27 09:48:24 EDT 2011
Jay,
For Navteq, you need to register as a developer so you can sign into the
http://www.nn4d.com/ site and from there you can download sample Navteq
data for some cities and some sample traffic data.
http://www.nn4d.com/site/global/build/traffic_apis/services/real_time_traffic/download_center/data_samples/p_data_samples.jsp
You can only download a single city worth of data, so look at what data
you need BEFORE you start download data.
I think I would pick Boston or Chicago. They only offer traffic data
for: Boston, Chicago, Houston, Los Angeles, SF
City street data:
http://www.nn4d.com/site/global/learn/freesampledata.jsp
Regarding http://bhelp.traffic.com/, this looks like a site that is more
geared to the mobile user that needs to see maps and get alerts when
roads they commonly use have traffic issues. I do not think this will
give you the raw data that would be useful for building time dependent
tables.
-Steve
On 5/26/2011 11:31 PM, Jay Mahadeokar wrote:
> Hi,
>
> We had discussed some possible ways of getting the test time-dependent
> data, but reached no particular solution.
>
> I found this link: http://bhelp.traffic.com/
>
> It a Navteq service and provides live traffic information. You need to
> login, and then you can browse live traffic.
> You can select each road and get following info:
>
> - Jam factor
> - Drive time now
> - delay
> - speed limit
> - average speed
>
> I guess, this is exactly what we need. Even if we can record the
> drive-time now, for each road at intervals of 1 hour each for a
> particular city, we will have significant time dependent data.
>
> I browsed the website but did not find any link where this data is made
> available. Is there any way to record this data? Any starting points?
>
> On Thu, Apr 7, 2011 at 10:05 PM, Jay Mahadeokar
> <jai.mahadeokar at gmail.com <mailto:jai.mahadeokar at gmail.com>> wrote:
>
> Hello all,
>
> Just an update - as Daniel suggested I posted a query about
> time-Dependent data in OSM routing list. It seems they dont have
> such data, but people have posted some things that might be useful
> for us in future. Here is link to the discussion -
> http://lists.openstreetmap.org/pipermail/routing/2011-April/001127.html
> You may want to have a look there.
>
> Sorry for the delayed replies, presently, I am a bit occupied by
> college submissions. I will go through the links and the ideas
> proposed here by Daniel and Steve soon. As already said I guess we
> need to put a lot of thought in designing the data model, that would
> be easy for users to use, robust and flexible for different
> applications, and at the same time efficient in terms of query and
> processing time. I will try and come up with thoughts on that soon.
>
> Regarding Navteq data, the website says that only one data-set will
> be allowed to download. So, I was wondering which data should be
> preferred. Also, there are various data-formats that Navteq provides
> data in. Steve, have you downloaded any data which specifically has
> time-dependent edge weights?
>
> Though we will not want the module to follow Navteq standards, any
> time-dependent data would be very helpful for me, since I also want
> to try out some heuristics on that as part of my thesis. The work
> done by R. Geisberger, P. Sanders and others is experimented on the
> Germany data provided by PTV AG
> http://www.ptvag.com/company/contact/. I have requested them data
> for research purposes. Have you worked with their data by any chance?
>
> Regards,
>
>
> On Tue, Apr 5, 2011 at 8:05 PM, Stephen Woodbridge
> <woodbri at swoodbridge.com <mailto:woodbri at swoodbridge.com>> wrote:
>
> On 4/5/2011 1:37 AM, Daniel Kastl wrote:
>
> Hi Jay,
>
> As Steve said, Navteq sample data is one possibility ... and
> it's better
> than nothing ;-)
>
> Well, I think we should avoid to support a single data
> provider, because
> who tells that the format they defined several years ago is
> the most
> suitable one. It might work perfectly for Navteq and road
> networks in
> countries they are operating, but this doesn't say there
> won't be a more
> clever way to store such an information.
> I think it will be always necessary to transform data into a
> format
> pgRouting algorithms can handle. So it's OK in my opinion to
> define some
> convenient format if there isn't an existing standard
> already (which
> doesn't exist afaik).
> But Navteq is good data for testing, I agree. For the
> beginning I think
> it might be even too complex model, as Steve mentioned there
> are even
> time dependent turn restrictions.
>
>
> I think that the value in looking at Navteq is not to use it
> all, but that it is a concrete data model that expresses all the
> various routing characteristics that you might run into in other
> data sets. Navteq has been the basis for almost all routing
> solution during the past 10-15 years. There are now others like
> TeleAtlas, and even OSM. So look it over and use as much or as
> little as you need to get started. Designing a data model is
> very complex and you can not do it in the abstract - you need to
> know what you are modeling.
>
> As far as defining an data model that is easy for users to work
> with, keep the tables simple to understand and load with data.
> It is better to have 5 simple to work with tables than 1-2
> complex ones. If you need to transform the data inside then have
> a preparation function that reads the user tables and applies
> them to the graph. So examples of user tables might be:
>
> o bus, train, ferry, airline schedules
> o live traffic data table
> o historical speed estimates by day/time (as Daniel mentions below)
> o transfer rules - required pre-deparature arrival time when
> transferring to a different transportation mode and
> post-scheduled arrival wait time when transferring from a mode.
> EG, must arrive at airport 2 hr before flight departure and
> allow 45 mins after arrival to collect baggage or longer on
> international flights. (this might not apply to your specific
> problem)
>
>
>
> A good place to discuss such a question might be also the
> "OSM routing"
> mailing list. In the worst case nobody will answer. But
> maybe you will
> start a long discussion as there are several people very
> interested in
> routing related topics. OSM data would be nice, if we could
> make use of
> it, but I fear that not many mappers really think about
> time-dependent attributes. Probably in Germany you can find
> such a data.
>
>
> Yes, working with OSM is another good possibility.
>
>
> I thought a bit about some possible cases for time dependent
> road networks:
>
> * In Japan a big issue for navigation software are so
> called "School
> Zones", which are areas around schools obviously,
> which are closed
> for motorized traffic at certain times in the morning.
> * In Europe I know about pedestrian areas for example,
> which can be
> used for delivery of goods after regular business
> hours. Or heavy
> trucks are not allowed to access roads during certain
> times.
> * Some highways/roads in Germany have a speed limit
> during night time
> * Ferry services might only operate during day time (so
> if you
> missed the last ferry, you might have to take a longer
> way)
> * In Japan they have so called VICS data
> (http://www.mlit.go.jp/road/ITS/conf/2006/ts20.pdf)
> collected from
> road sensors, which can tell the typical speed on
> roads during
> certain hours.
>
> ... and so on ...
>
>
> One last thought on loading data. I work a lot with Navteq and
> LOTS of other data sets. The one common theme that I come back
> to is that I create data loaders for the various data sets I
> work with so I can load the data into the database and I always
> end up transforming the data into a simpler model that is easy
> to work with and then used by whatever application I am working
> on. Sometimes I transform the data in the loader and sometimes I
> just load it raw and transform it in the database and then drop
> the raw data tables.
>
> Hope this helps,
> -Steve
>
>
> I think what pgRouting is currently missing are some sort of
> "unit
> tests" on some test network. This can be a regular grid with
> costs
> assigned, that model a certain routing case. It would be really
> convenient to have something like this.
>
> Daniel
>
>
> 2011/4/5 Jay Mahadeokar <jai.mahadeokar at gmail.com
> <mailto:jai.mahadeokar at gmail.com>
> <mailto:jai.mahadeokar at gmail.com
> <mailto:jai.mahadeokar at gmail.com>>>
>
> 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>
> <mailto: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>
> <mailto:pgrouting-dev at lists.osgeo.org
> <mailto:pgrouting-dev at lists.osgeo.org>>
>
> 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>
> <mailto:pgrouting-dev at lists.osgeo.org
> <mailto:pgrouting-dev at lists.osgeo.org>>
>
> http://lists.osgeo.org/mailman/listinfo/pgrouting-dev
>
>
>
>
> --
> Georepublic UG & Georepublic Japan
> eMail: daniel.kastl at georepublic.de
> <mailto:daniel.kastl at georepublic.de>
> <mailto:daniel.kastl at georepublic.de
> <mailto:daniel.kastl at georepublic.de>>
> Web: http://georepublic.de <http://georepublic.de/>
>
>
>
>
> _______________________________________________
> 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
>
>
> _______________________________________________
> 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
>
>
>
>
> --
> Regards,
> -Jay Mahadeokar
>
>
>
> _______________________________________________
> pgrouting-dev mailing list
> pgrouting-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/pgrouting-dev
More information about the pgrouting-dev
mailing list