Additional UI Elements

Stephan and me added some additional UI elements to the settings dialogue of the Roadstar webview.
At the moment, the elements are not yet connected to any functions. This will happen the next week.

We added some radio buttons for line or point view  and a slider, where the density of the showed data can be chosen. In addition to that, you can decide whether to see raw data or map-matched data. Finally we created some smileys for the different qualities. By clicking on them you will be able to choose different quality filters.

In the “About” dialogue, we added a link to this dev blog.

Bildschirmfoto vom 2015-06-15 20:56:42

Advertisements

Node-osrm – An alternativ mapmatching solution

The alternative

After testing and trying to patch the graphhopper map-matching framework, I decided to have a second look for alternative map matching frameworks. After googling for a long while and trying various search terms, I found the Project-OSRM on Github.

The Open Source Routing Machine (OSRM) is a C++ implementation of a high-performance routing engine for shortest paths in road networks. – project-osrm.com

Thankfully this project also comes with a repository containing NodeJS bindings for OSRM. It gives us various wrappers to access the routing functionality. Many examples can be found in the readme on github. The one especially useful for use, as it enables us to do point per point map matching, is:

osrm.locate([52.4224,13.333086], function (err, result) {
  console.log(result);
  // Output: {"status":0,"mapped_coordinate":[52.422442,13.332101]}
});

Setup

The Setup is described in the projects readme as well, however there are a few challenges to tackle:

  • Use the current official node version, as there seem to be bugs under iojs
  • You seem to have to run the make command first, before being able to create supporting files.
  • The node module needs various files, such as *.edges, *.nodes, … to work, which are generated after running the make command as shown in the readme. In order to support map-matching for a bigger area, you need to change the default area (berlin) to the wanted area. Be aware that this might take a lot of time for bigger areas, as it downloads the whole .pbf file from the web (e.g. germany ~2.6 GB)
  • There where a few more challenges, i will update this list as I remember 😉

Results

After setting everything up, some test runs with existing data where made. In general, the map-matching worked pretty well and reasonably fast. However, as this does the map-matching point by point,  there are a few outliers visible. Some pictures of the results can be seen below. Note that the only the pink points are the map matched ones, all other ones are “raw data (e.g. yellow, green, red, …)

screen_shot_2015-05-20_at_13.51.58_1024

Patching Graphhopper

For displaying our collected data on a map, we have to make sure, that the gps data is right on the road. The individual points need to snap to the streets and than show the quality there. This process is called Map-Matching. We looked into current solutions and stumbled upon Graphhopper, which is a routing framework with this functionality right built in.
Graphhopper would fit perfect in our pipeline, but there is a mayor problem.
After some tests we realized, that the map matching part works flawlessly, but after the procession, all added extra data, like quality measurement data is lost. Also the timestamps are gone. This is a serious problem we need to work around. We basicly lose the ability to map the quality data to the street.
Graphhopper is open source. So we contacted the developer and looked into the GitHub Repository. It shouldn’t be too hard to patch Graphhopper ourselves. After working trough the code, we saw another problem.
The algorithm does not only snap existing gps waypoints to the road, it also creates new ones. And for these new ones, there are no quality data available. Also the timestamps are lost because of that reasion.

In the end, we created or more or less working hack, that takes the data for one waypoint and spreads it to all new waypoints that are created from this one. That waorks okayis and we will have to test further how it will work with large datasets.

The issue with the timestamps is still in progress. We will try to interpolate between the waypoints, and calculate the new time.

All of this will be a ongoing task. We decided that it is more important to finish the gathering of data, its storage and interpretation. We will get in contact with the developer of Graphhopper again and ask for help.

Graphhopper Map-Matching

As with all wireless technologies, there are times of disconnection and data loss. It’s not different with GPS. Imagine we’ll use our Roadstar hardware on a test route, and just in the moment of turning into another road the GPS signal is lost. The result would be a line on our map, which would not go around the corner, but straight through e.g. some buildings.
In order to avoid such errors, we want to include the Graphhopper map-matching algorithm into Roadstar. As already mentioned in a former post, there is the problem, that during the calculation of matching GPS data, all other data (e.g. sensor data) stored in the original GPX file is lost. That’s why we have to patch the procedure, so that it will fit and keep our GPX data structure.

Unfortunately I completely underestimated this task. In addition to the loss of our sensor data, there is another problem. During its calculations, the algorithm creates some new GPS points in order to fit the map structure. These points won’t have any sensor data. We’ll have to discuss, how we’ll handle that.

Because of a lack of time, I just started setting up the different Graphhopper projects on my computer and reading the docs. I’ll have to get into the Maven dependency management, too. Next week we’ll probably distribute this task on more than one person, so that there will be some nice results as soon as possible.

Planning a NodeJS backend architecture for the RoadStar project

After evaluating the task of creating a backend for storage of measurement and gps data and displaying it on a map, it is time to think about how to put the pieces together.

What we want to use

  • MongoDB for storage
  • GraphHopper/mapmatching for matching the measured position of the GPS sensor to the nearest street
  • Express/NodeJS API enabling access to the stored data from the outside
  • Leaflet for displaying the data on a map
  • GPS and gyro sensors on a Raspberry Pi

MongoDB allows us to store the JSON which contains the measured data as is. This comes in handy, because no conversion needs to be done internally. But wait… The GraphHopper only accepts data in the gpx format, a XML standard for storing geo data. And there also is Leaflet, which works best with GeoJSON, another predefined standard, this time JSON again. This problem of different data formats can only be solved by creating and/or using existing converters. This adds another piece to our architecture, the

  • custom converter

Having all these pieces and different formats, the need for a first overview arises. After sketching and refining, i came to the following concept:

architecture

A first concept of an architecture

The next steps will be creating some of the parts and check whether this architecture will stand the test 🙂

MapView & Map-Matching

Last week I decided to choose Polymaps as the mapping framework, which should present our results. Trying to add some more gimmicks to the map, I found out for myself, that it is pretty uncomfortable to add for example small popups to the map.

Because of that I tried another framework (leaflet.js). Instead of using an SVG layer, it uses an own vector layer to show up markers and lines. All in all that framwork is way easier to use and has a lot of more documentation in the web. The only disadvantage is the strange zooming behaviour of the geoJson layer data. It always keeps the same size, which looks bad on very high/low zoom levels. We’ll find a workaround for that! Moreover I got some nice, more minimalistic (in comparison to the standard OSM) map tiles from mapbox.

In addition to that I tried out the map-matching framework from graphhopper, which seems to work pretty nice, but has a big disadvantage of losing all the metadata from GPX files. We’ll have to rewrite some Java classes, so that it fits our GPX structure and will keep the important sensor data in it. This will be one of the main tasks for next week.

How to display our data on a map

In order to visualize the results of the data we receive from Raspberry Pi, a map framework for JavaScript is needed.

During my research I found this pretty helpful website, which compares many frameworks. All in all Polymaps seems to be a nice solution. It works with CloudData, OpenStreetMap or Bing map tiles. Additionally it offers the possibility to create SVG layers upon the mapview. Using that in combination with geoJSON data, you can easily colorize the map.

I set up a small example (see screenshot below), where you can see how it could look like. In order to get the geoJSON dummy data, I used geojson.io.

mapview - example