Jay,
I have downloaded all the data for April 2011 for the California sensors based on hourly stats from:
http://pems.dot.ca.gov/?dnode=State&content=dbx&tab=dbx_download
You have to create an account and login to get to the data.
Here is a description of the data fields:
http://pems.dot.ca.gov/Help/context.phtml?content=ctx&dnode=State&topic=dbx#text-station_hour
You can also download raw sensor data, 5 min, 1 hr, 1 day data summaries. It's a lot of data! If someone wanted to get fancy/crazy? they could download a years worth of data or multiple years and then try to summarize that in hourly data by day of week, holidays, etc.
Each sensor is located by both a lat/long position and a description and has average speed over the interval being collected, into addition to number of lanes, and vehicle counts.
There are 9 separate coverage areas in California that the data is grouped into.
My thought is to some day I'll do something with this data if I can get a routable data set for California maybe able to use OSM data for this.
-Steve
On 5/27/2011 10:42 AM, Stephen Woodbridge wrote:
Correction: TMC - Traffic Message Channel or Traffic Management Center
On 5/27/2011 10:18 AM, Stephen Woodbridge wrote:
Jay,
Trying to narrow down some google searches this looks like it might have
some promising candidates:http://www.google.com/#q=traffic+data+feed+data+standards+tmc+adms
ADMS - Archived Data Management Systems
TMC - Traffic control centersThis looks like a potential site for getting archived real-time data:
https://pems.eecs.berkeley.edu/?redirect=%2F%3Fdnode%3DState
http://pems.dot.ca.gov/So from a project point of view, I'm not sure it is a good idea to spend
much time research potential data sources and coding tools to summarize
the data into tables. While this is clearly interesting and might be a
good ideas after GSoC, I think it might be a huge time sync and it would
be better to just make some test networks by hand.One of the problems you will run into with most if not all of these
sites, is mapping sensors to edges. This might not be hard if the supply
the lat/lon of the sensor, but in may cases I think they just supply a
textual description of the sense and you have to map that to a edge.-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 speedI 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@gmail.com <mailto:jai.mahadeokar@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@swoodbridge.com <mailto:woodbri@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 nothingWell, 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,
-SteveI 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@gmail.com
<mailto:jai.mahadeokar@gmail.com>
<mailto:jai.mahadeokar@gmail.com
<mailto:jai.mahadeokar@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@swoodbridge.com <mailto:woodbri@swoodbridge.com>
<mailto:woodbri@swoodbridge.com
<mailto:woodbri@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@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/pgrouting-dev_______________________________________________
pgrouting-dev mailing list
pgrouting-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/pgrouting-dev
