What does TrackMatching provide?
TrackMatching performs the map-matching of location data (e.g. GPS/GPX tracks) against the OpenStreetMap road network. The service is primarily intended for car data for now. The service is provided as a SaaS (“Software as a Service”) running on Amazon cloud platform.
How to use the service?
The service is accessible via a REST API. Invocation is straightforward either from the command line, scripts or any computer language.
Which input formats are supported?
TrackMatching supports GPX1.0, GPX1.1 and a custom CSV/Text format for bulk processing. Only positions and timestamps are required. Additional data such as GPS quality indicators or headings are not used. See File Formats.
Instead of OpenStreetMap, can we use the network from vendor XYZ?
TrackMatching can be deployed privately for customers who own licenses for other network vectors such as TeleAtlas or Navteq.
How to import the results into a specific GIS?
The results are provided in XML and JSON text formats. These can be easily converted to GIS features. Tell us if you need customization services or support for specific formats.
What about privacy?
What about security?
GPS log files are never persisted. The data is therefore mostly exposed during transfer. The service uses HTTP/HTTPS protocol.
Why a SaaS instead of locally installed software?
Cost, scalability and maintenance. You pay only for the volume of data that you need to process, no license fees. The service runs in the cloud and can accomodate the processing of very large amounts of data. State-of-the-art algorithms are regularly tested and implemented to deliver optimal performance.
We hit the API limits, can we get more quota?
Contact us to extend your quota. We are currently in the trial phase and we’ll provide pay-per-use capacity in the future.
How much will the service cost?
The service will remain free for casual low-volume users as well as developers evaluating the API to build early stage applications.
The demo reports inaccurate matching. Why?
Most of the time the reason is not the quality of the GPS data itself but data lying outside the road network or being too sparse. The current matching algorithm works also best with large volumes of car data with high-frequency. For low-frequency (e.g. one data per minute), path inference is still limited. Pedestrians streets, hiking trails and bicycle paths are not currently included in the matching road network. You can help to improve the service by sending us tracks which were not accurate enough.
The matching track is split in too many routes. Why?
The current algorithm does not attempt to merge the several ‘GPX tracks’ from a GPX log file. Routes are also split when there is no data for a long time period.
What are the different performances reported in the demo?
Processing time corresponds to CPU time actually spent by the servers matching the data once the data were uploaded. Delivering back data to the demo also includes an overhead. Processing time gives the best approximation of the throughput that can be expected of bulk processing from an application using the REST API.
Which part of OpenStreetMap does it match against?
The service covers the whole world but is currently limited to the road network for motorized vehicles.
Does it work with other transport modes than the car?
The service currently supports only the road network. Extension to pedestrians ways and other networks (e.g. rail) is being considered.