After more than one year of silence - working with more or less perseverance on this project - here are some news:
My domain name jamdroid.org was stolen by a UK-based company (enom.com, you bandits). I lost my web site, and only have this blog left. Hence the discontinued communication! I won't put another website online.
I managed to get a runnable alpha version of Jamdroid, that worked with OpenStreetMap data - hail to them, they do a really great job. Of course, a lot of work remains: user interface, data refinement and accuracy, integration API for GPS navigator software, etc.
Most importantly, Google announced yesterday a project similar to Jamdroid. Obviously, they will provide a much better service, and they have many more resource and weight to put in the balance than I will ever get. I guess it means the end of Jamdroid - I won't put any more efforts on this project.
It was a risk to take when launching this project: it realized. Good luck to them!
Thanks for those who supported me, or at least have shown interest in this idea.
Jamdroid is dead, long live Jamdroid!
After more than one year of silence - working with more or less perseverance on this project - here are some news:
As soon as I get some free time, I'll post a few explanation screenshots, and maybe a demo version. Stay alert...
There we go. This video is quite old, and was recorded with a prototype version (no UI, ugly graphics, etc.)
[Edit: Jamdroid was mentioned in a Wired article about the Android platform!]
As of now, GPS is an almost ubiquitous technology. For an average consumer, a GPS navigation software basically allows:
- to find the shortest - or fastest - path to an address.
The first point is well covered by the commercial solutions currently available. As for the second one, current products are able to figure the quickest route to the address, although using statically 'pre-defined' speeds, depending of the road used (130 km/h on an highway, 50 km/h inside a city, etc.). Nevertheless, the information it provides is accurate only when there is little or no traffic. When the user is stuck into a traffic jam, the total time for his travel is tragically increased.
Some entities - mainly 'institutional', such as state road departments, etc. - provide traffic information to an operator, that sends it to the user, generally against a subscription to its service. Though quite accurate, this information lacks two important things:
- it is not completely real-time, and generally based on short terms previsions
- it only deals with highways, freeways, sometimes main streets in large cities.
Jamdroid is a totally new concept, that proposes to address the points mentioned above.
What is Jamdroid?
Jamdroid is an application developed for the Android platform. Its goal is to provide real-time accurate information about road traffic, virtually anywhere on the globe, based on the idea that anyone driving a car with a gps receiver can have its device estimate the traffic he just went through.
Jamdroid supposes that each user owns an Android-capable device, with a GPS receiver, that has a permanent connection to the Internet. The devices will connect to a main Internet server, that receives their information, and sends other users report as a reply.
All Jamdroid users are part of a community: everyone sends traffic information for the route he just went through, and receive information about the traffic in the area he is going toward.
Jamdroid’s goal is to be complementary to existing traffic services – such as that of GoogleMaps – to improve the users experience.
- When a user drives his car, Jamdroid analyse the device speed and position in real-time, to calculate a detailed traffic report on the current road or street the user is driving on.
- Once a significant piece of information about the traffic has been extracted, it is sent to an Internet server, that memorises it.
- When a user starts the GPS application, Jamdroid registers to the server, with its current location.
- The server pushes traffic data it receives to all registered client driving in the corresponding area.
- A client can also directly request traffic information in a specific area - say, to prepare a travel.
What is not Jamdroid?
- A (standalone) GPS navigation software. Such programs already exist - particularly on the Android platform, on which there will probably be a lot of different application, due to the simplicity and abundance of the necessary API (LocationService, GoogleMaps, etc.). Jamdroid is meant to be integrated in such products, to retrieve and provide them with traffic information. However, Jamdroid is still a standalone product - since it is under development, and is not integrated into any other software; it displays a standard Android MapView, that is 'overlayed' to display the current road and traffic.
- A finished application! It is still under development and needs heavy testing and customisation that can only be achieved with high-scale tests, on a real device. See Developments and Enhancements for further explanations.
Jamdroid retrieves each location provided by the GPS (LocationProvider). It reads its position, bearing, speed and time into a JDPoint.
From the collection of JDPoints, it extracts 'segments' (JDTraffic), which consist of:
- an array of consecutive points
- with the same bearing
- no longer than a customisable size - eg. 100 m in a city, 5 km on a highway.
- considered 'homogeneous' in terms of traffic intensity.
When a new JDTraffic is built, it is analysed, to get an estimation of the traffic. Simply put, it runs a pattern recognition algorithm, that:
- detects and removes 'normal' stops (traffic light).
- extracts the max speed on the segment, the average speed, and the 'jitter' (being the average of the differences between each JDPoint speed and the max speed)
- finds low-speed segments - that are not due to 'normal stops'
- compare the max and average speeds to the type of the road, if available (needs a precise reverse-GeoCoding, not implemented yet.)
The results of these steps allow to define:
- a traffic rate (percentage, 0% being 'fluid road')
- a reliability of the accuracy of this rate (percentage, 0% being 'highly doubtable’ (!)).
The reliability depends on how well the pattern were recognised in the JDTraffic.
If other users went through the same segment 'recently', Jamdroid already has a JDTraffic (received from the server) describing this portion of the road.
The JDTraffic segment is then compared and merged with previous segments. It allows to improve the reliability of the information, according to the following considerations.
- The more users report an information, the more reliable it is.
- The more similar traffic rates are amongst all users, the more reliable it is.
- The more recent, the more reliable
- 'Fluid traffic' is by essence more reliable than 'congested': a car cannot go faster than the traffic, though it can go slower.
- Motorbikes and scooters are not reliable: they can usually run faster than cars in a traffic jam. So are bicycles, pedestrians, trucks, delivery vehicles. Those users can be flagged as 'unreliable'. Thus, they will receive traffic information, but the data they report will not be used buy other users. On an early stage, Jamdroid is designed for the majority of GPS users: cars.
Once processed, the JDTraffic is ready to be sent to the server, to get forwarded to the other users.
(Note: the following refers to the current version of Jamdroid, that has not been integrated into any other GPS product yet. Thus it uses a standard Android MapView to display the data to the user)
When a user receives a new - or updated - JDTraffic, it is displayed on its map as an Overlay. The system distinguish between several levels of congestion:
- LOCKED (0-25%): one can hardly move its car.
- JAMMED (25 - 50%): heavy congestion
- CROWDED (50 - 75%): one runs slower than normal.
- FLUID (75-100%): no congestion problems.
It is displayed as black, red, orange and green segments directly on the map, over the road/street.
The community - The Internet server
The potential strength of Jamdroid comes from the community that we will build around it: without a sufficient user basis in a particular area, it will not be useful to anyone! This is why we thrive on convincing a lot of Android users to run Jamdroid with their GPS software.
Indeed, Jamdroid proposes a new approach to GPS navigation: due to the lack of detailed traffic information in particular area - say, in city centres - people that use their car to go to a place they know don't feel that they need to use their GPS! With Jamdroid, anyone that takes its car to go to work will be informed in real-time of the traffic conditions, the time he can estimate to his destination, the best way (if it exists!) to take, etc. By turning his GPS on, the user will benefit from other users information, and he will provide new - or updated, more accurate - traffic information to the community.
An important aspect to federate a 'community' will be to develop a website that anyone can refer to, ask questions, participate in a forum, etc. Each active user will get a unique identifier - known by its device - that allows to organise small 'challenges'. For instance, as expressed before, JDTraffic are associated with a 'reliability'. Thus, the overall reliability of a player wan be determined, and lead to a 'Top 10 reliable users'. In the same way, we will rank 'Top 10 traffic reporter of the month', for the users that contribute the most to the community.
Of course, associating specific GPS locations at a particular time to identified reasons can lead to legitimate concerns about the users privacy. This will be addressed with the help of external instances which purpose is to verify such data recordings (CNIL, www.cnil.fr, France). Moreover, users will be able to disable the identification of the data they send to the server. Finally, the exchange communication protocol will probably be released publicly, to be reviewed by anyone that wants to have an insight into it.
Technical details of the Web Service
When a user starts Jamdroid, it connects to the public Internet server. It then send to the server a 'Subscription' request, specifying its current area, or any area it is likely to be interested in - for instance if he's planning a long trip.
The server sorts all connected users, according to the area they have registered into.
It also memorises in a database all traffic data it has received from clients.
- When a user enters (registers) an area, all the traffic information known by the server about this area is sent to the Jamdroid client.
- When a user exits an area, it can 'Un-subscribe' for this area, and 'Subscribe' for another one (or several others).
- When a user runs through a street and process a JDTraffic information (a new one, or an update to an existing one), it sends it to the server, that updates its traffic database. The JDTraffic is then sent to every user that has registered for the current area. Of course, Jamdroid will update the map of the client, if necessary.
After some time, traffic information is just not useful anymore, since its reliability decreases when the time since initial analysis increases. At some point - customisable, but around an hour, it can be just ignored. The server removes outdated data from its database.
Current developments and future enhancements
To be fixed
Jamdroid is still on an early stage. The traffic recognition algorithm, yet implemented, needs high-scale testing with various sets of data, to improve the values of each parameter. This cannot be tested without actual devices, and reviewed by a human eye. (The notion of a 'jammed' or 'congested' road is somewhat subtle, and depends on the user's sensibility). An alpha-test experiment will be conducted as soon as devices are delivered to the public. It will involve any willing 'early-adopter' that wants to help us improve the overall accuracy and reliability of the software.
In the same way, the server will need to be tested under heavy load, to ensure its constant availability.
Jamdroid needs to find partnerships with GPS navigation products - at least to define a stable API for them to integrate.
The website - offline for now - needs to be completed and set on-line, to help a community to grow around it. At first, it will be aimed to the important community of Android fans and developers, that would like to discover and experiments such new products.
- Implement user properties, such as:
o Turn on/off user actions: during the 'test phase', Jamdroid may ask the user to confirm or infirm the state of the traffic it just analyzed. This will contribute to the overall reliability of the algorithm, but needs an action from the user.
o Reliability threshold (only draw reliable enough segments)
o UserID: if the user wants to be displayed on the Web site statistics, he may enter a UserID - linked to a Web account - to have the server record the amount and reliability of the data he sends.
o Data displayed: traffic segments (green, orange, red, etc.), reliability of the segment,
- Build a strong partnership with a 'recommended by Jamdroid' GPS software, or fork the project to develop its own GPS navigation application, tightly bound to Jamdroid. This way, Jamdroid will be set as an Android Service, rather than an Activity.
- Jamdroid can be viewed as a mean for users to exchange various information (more than just traffic) about the road they are on. We can imagine that someone passing in front of a radar could just 'warn' other users by pushing a 'report a radar' button, that will automatically be sent to other users in the area. In the same way, several kind of useful information can be reported: accident, street under construction, weather conditions, wonderful landscape, cheap gas station, 'Jamdroid community meeting point'...
- Another extension would be to allow several users to create a 'link', and transmit in real-time their respective positions one to another. Say, friends go on a road trip with two cars; the second car blindly follows the first one (the one that knows the particular restaurant they want to go to). If they ever get separated - by a traffic light, a wrong turn, the need to fix a wheel, etc, the second car can easily find its way back, since the driver can view on the map the exact path the first car went through.
- Add direct P2P connection to decrease the load on the server. It could also allow particular clients to communicate directly through WiFi – if close enough – or SMS to exchange data.