LWN.net Logo

TomTom unveils OpenLR location-referencing format

September 23, 2009

This article was contributed by Nathan Willis

On September 8, GPS device maker and mapping service provider TomTom pulled back the curtain on what it hopes will become an industry-wide standard for location referencing and dynamic route guidance. OpenLR, as it is known, is designed to allow heterogeneous applications and services to exchange location information in a compact, map-agnostic manner, which would ease the burden of interoperability between Web map services, car navigation devices, and other content systems that provide location-sensitive data such as public safety warnings. TomTom said it wants OpenLR to be a royalty-free, open specification, with a GPLv2-licensed encoder and decoder that will come shortly.

The company has long used Linux and open source software in its hardware products, which led to the famous patent lawsuit with Microsoft in February of 2009, over the VFAT filesystem. TomTom counter-sued Microsoft for patent infringement, and the two companies settled out-of-court in March. Despite its history with the open source community and development model, OpenLR is TomTom's first attempt at launching a completely new open source project of its own.

OpenLR bird's eye view

The problem OpenLR is designed to solve is rapid exchange of location-relevant content between independent data providers, aggregators, and end-user devices. OpenLR is not a geographic coordinate system (such as World Geodetic System 84 (WGS 84)) or a markup language akin to KML or GPX. Rather, OpenLR focuses on encoding location reference points (LRPs) using a combination of coordinates and attributes such as functional road class (FRC) and form of way (FOW) that describe the LRP in terms of its physical attributes. Thus, an application using a map from a web-based mapping service and directions from a GPS device can decode an LRP using multiple factors and determine that it is the same location, even if they use different map formats or disagree slightly.

In spite of the name "location reference point," as it is defined by OpenLR, an LRP is more like what a mathematician might call a directed graph edge: it has a start and end node, a bearing (compass direction), and a length. This evidences OpenLR's underlying goal of describing travel rather than precisely pinpointing stationary objects, but the terminology could still be confusing for newcomers. FRC and FOW likewise focus the attention on roads; FRC is defined as a number from FRC 0 ("main road"), to FRC 1 ("first class road") all the way down to FRC 7 ("other road"). FOW describes the physical type of road: motorway, roundabout, traffic square, and so on.

The primary use case TomTom outlines for OpenLR is to describe "line locations," which it defines as the concatenation of shortest paths covering a set of LRPs. OpenLR itself does not calculate the shortest or best path between a start LRP and end LRP; it merely provides a way for the software to encode it for exchange in a bandwidth-friendly way. OpenLR is not concerned with other map elements found along the way, such as geographical features or points of interest (POIs).

Routing between selected locations is arguably the easiest scenario to imagine; a device could request a route between two points and receive directions back from a remote server as OpenLR data. In addition, TomTom describes several cases where OpenLR might be used to propagate other information useful to travelers, such as traffic congestion data, public safety warnings, and even cooperative vehicle-to-vehicle communication — all of which share the same need for shortest-path routing information — plus applications useful to municipalities such as real-time urban traffic management and toll-road usage information.

Openness

TomTom's OpenLR Introduction [PDF] says that OpenLR is designed to be map-agnostic (meaning that OpenLR data is independent of both the map vendor and map version), communication-channel independent (so it can be transmitted just as easily by radio broadcast or over an IP network), and encoder independent (so that any device, application, or service can unambiguously decode the information sent by any other). The company has posted a more detailed description of the OpenLR data format in a white paper [PDF] available on its web site, including the byte-oriented stream format and details about how to specify each component, from coordinates (in WGS 84) to bearings and distances.

In its presentation, the company explains the value of releasing OpenLR as an open standard — better buy-in from key industry stakeholders, security against intellectual property threats, and flexibility to expand and enhance the standard in the direction chosen by the community. TomTom has filed for patent on the core concept in OpenLR, but says that it will publish the method used in the patent in its GPL-licensed encoder and decoder implementation. The documentation itself is published under the Creative Commons CC-BY license.

TomTom explains in the presentation that it chose the GPLv2 for OpenLR's license in order to protect free implementations from patent attack, noting that commercial services can still deploy the software. It also says that the license to use OpenLR will include a non-assertion clause. Complete details are provided in a separate license document [PDF].

Although TomTom says it will take the leadership and maintenance role in OpenLR's development, the white paper and presentation both assert that the company wants and expects the open source community to participate in expanding OpenLR, including the coverage of different types of data (such as Points and Areas), support for different formatting option such as XML, integration with GPS and Galileo positioning systems, and integration with the Transport Protocol Experts Group (TPEG) traffic and travel information standard.

The race is on

The core data covered in OpenLR's route-and-traffic exchange usage scenario can also be expressed in other, existing formats. The most widely-known is Radio Data System Traffic Message Channel (RDS-TMC), a format broadcast in a data sideband of standard FM radio transmissions. RDS-TMC is widely deployed in just a few countries, notably Germany, though it is available around Western Europe and North America. RDS-TMC traffic data itself can originate from a number of sources, including government-deployed road sensors, and the format itself is published.

Nevertheless, using RDS-TMC is problematic — particularly for free software — because it encodes the actual locations referenced via a copyrighted data set, one which is limited in size and not easily updated or corrected. A system similar in scope called AGORA-C is proprietary and commercial, relying on licensing and royalty collection, which has led to uncertain commitment from industry players. The TPEG format TomTom alluded to it its presentation is open, but TomTom regards its current location-referencing subsystem (TPEG-Loc) as unsuitable because of a lack of standardized encoding rules.

The market for location-referencing is large; free routing services from the likes of Google and Yahoo do not bring in any revenue, but in-car navigation systems (both built-in and aftermarket) are reportedly a huge and still-growing business. TomTom itself sells navigation software for platforms like the iPhone, and fee-based services for drivers to avoid speed traps and other road hazards. TomTom also owns map maker Tele Atlas, which it acquired in 2007.

Competition between TomTom and mapping rivals like Garmin and DeLorme in this space is fierce; the financial stakes are high and the number of players is low. That is a situation which free software advocates recognize has prompted the strategic release of a core technology as open source many times before. OpenLR certainly meets a need in the navigation stack; open projects like OpenStreetMap cannot use alternative systems such as RDS-TMC or AGORA-C because of their licensing. Nevertheless, OpenLR's openness is no silver bullet; for it to make a substantial impact it will still have to be adopted by multiple industry players, including traffic data providers.

Of course, an active show of participation on the standard from the open source and open standards communities could go a long way in making that happen. TomTom is expected to present about OpenLR this week at the World Congress on Intelligent Transport Systems. The reaction there will say a lot about the industry's take on the technology. For the open source community's reaction, one will probably have to wait for the still-to-come source code release.


(Log in to post comments)

vehicle-centric standard?

Posted Sep 29, 2009 22:23 UTC (Tue) by roelofs (guest, #2599) [Link]

OpenLR seems remarkably automobile-centric for a standard proposed by a European company. Virtually everything refers to roads; there is no concept of a bicycle-only, bike/pedestrian-only, or pedestrian-only path. (The only almost-exception is the TRAFFICSQUARE form of way, which describes "an open area ... which is used for non-traffic purposes," but even that is "(partly) enclosed by roads" and obviously doesn't capture the bike- or pedestrian-path concept.)

One of the major mapping services (Google, I think) recently noted several of the problems with such an approach: there are roads and bridges on which pedestrians and/or bicycles are banned (e.g., freeways); roads on which vehicles are restricted to a single direction but pedestrians (and possibly bikes) aren't; and obviously paths, walkways, etc., on which vehicles are banned (and perhaps also on which bicycles are banned or impractical, such as stairways, trains/subways, or the Pacific Crest Trail). If you're explicitly looking for a bike route to work or a pedestrian path in a remote tourist location, vehicle-oriented GPS receivers and mapping services are often useless.

Greg

vehicle-centric standard?

Posted Sep 30, 2009 0:06 UTC (Wed) by dlang (✭ supporter ✭, #313) [Link]

true, but it would still be FAR better than the current situation where everyone keeps the data walled up and separate.

if someone has a suggestion as to how to alter the proposed standard to better support these other options, by all means make it.

however, you don't want use of this to flounder due to efforts to make it perfect.

it's a lot easier to supplement a vehicle-biased database like this with additional data than to create it from scratch.

vehicle-centric standard?

Posted Oct 1, 2009 3:23 UTC (Thu) by roelofs (guest, #2599) [Link]

it's a lot easier to supplement a vehicle-biased database like this with additional data than to create it from scratch.

Good points all, but the flip side is that standards become much harder to change after everything's baked in (unless they're explicitly designed for extensibility, like PNG), and many early adopters never get around to updating their code to later versions. In this case, both of the fields I mentioned are explicitly limited to 3 bits, i.e., just enough to support the 8 values they've already defined, and I see no allowance for any sort of "escape value" or other form of extension. Seems like premature optimization.

I'll try to submit a comment to their standardization process...

Greg

Copyright © 2009, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds