How is using an API different from licensing data

Because the needs of location-powered apps are so varied and diverse, the goal of this new article series is to unbox the products, services, and information which are all built on and powered by our Map Data at TomTom. This series is applicable to anyone in the location services space who is looking to place key mapping services behind their product, with the idea being to inspire you to build bigger and better solutions to the world’s mobility challenges.

Deconstructing products in the mapmaking ecosystem

Location data has become ubiquitous and essential for a variety of applications in our modern software ecosystem, and the scope is very, very broad – some services require detailed, highly precise and up-to-date information to keep the world safe, minute to minute, while your local bookstore might also need a map on their website showing that they’re behind a historic building, not on the next side-street. No matter the level of detail and precision services need, location data is important, which is why multiple options for accessing it exist to serve countless use cases.

What we mean when we say “Map Data”

When I talk about data, I’ll be referencing the core information that TomTom’s products run on, in order to provide the freshest, most accurate location services possible. When we talk about Map Data in a geospatial sense, we really refer to data collected over time which allows users to build a digital model of the real world through mapping products – essentially, the function of maps as you know them. The key difference is that beyond the era of paper maps, location data is available in different formats: in bulk, able to be transformed for a specific use, or accessible as a managed, existing online map.

Primarily, I’ll be focusing on the difference between licensing our Map Data, aka our uncompiled maps, and using our Maps APIs and SDKs, accessible with accompanying documentation on our Developer Portal. Because each format has distinct limits and advantages, exploring them in greater detail can help businesses decide which mapping path is best for them. I’ll start off as high level as possible, and work in more technical details the further we go.

But first, a primer on Data Layers

Most commonly, questions come our way about what constitutes map data at TomTom. Data exists in layers, which we know as map details: this is information we collect about roads worldwide to support routing and overall guidance.

Road information includes aspects such as:

• Digital elevation

• Road curvature and gradience

• One-way streets, closures, and turn restrictions

• Signage

• Average speeds traveled during each hour, each day, and each year of a segment of road: Speed Profiles

• Road types

• Lane information

• Verified Speed limits

• Bifurcation (road splits, forks, etc.)

• Street Geometry

Additionally, this data is further extended to support door to door navigation via:

• Address points

• Building entry points

• House number ranges

Which all help distinguish physical entry points to locations and places of interest (POIs, aka, businesses) from physical addresses – which, if you’ve taken rideshare enough, you know are not always the same.

What does it mean to license data from TomTom?

Licensing map data from TomTom means you are getting access to uncompiled maps via our flagship product Multinet-R. “Uncompiled maps” can be thought of as all the comprehensive ingredients for the perfect map, unmixed – a means to an end.

Multinet-R represents a way of modeling these mapping ingredients – that is, the map data. When the data files are loaded into a supported relational database (RDBMS) using our data model, the customer can then create views that join multiple tables from our data model to create representations that work for their specific use cases.

Essentially, this means that these “mapping ingredients” are delivered in a format where the customer can do the final mixing themselves.

How is using an API different from licensing data?

Contrasting with uncompiled maps, our Maps APIs are an online, managed service. If Multinet-R represents unmixed ingredients, REST APIs represent placing an online order for the finished product.

While Multinet-R allows for the customization of how a large amount of data is queried, structured and used for a tailored solution, it requires all of that heavy lifting before an application runs with that desired outcome. To shortcut this, behind the APIs are existing data models optimized for search queries, and predetermined parameters to help aid developers in queries.

When you interact with the Maps APIs, TomTom is managing cloud deployment, scaling, infrastructure, uptime, etc. – no behind the scenes looking necessary. Online queries return the map information indicated in the documentation, and return a map display, route, traffic layer, search results and the like.

Is it the same data?

We use the same uncompiled map; simply, data used within the is APIs optimized for those calls. Behind the APIs are data models, which organize the data so that all of those mapping details already have structure and representation which is predefined and quickly accessible online. This predefined setup allows for parameters, which are how developers can customize queries to return the exact kind of information they are looking to represent in the final product.

How is my application’s relationship to the map different with each?

Very simply put, both formats use the same data sources, but the access style and level of depth are different. Multinet-R leverages the bulk of all available mapping details in a database-accessible format, but requires a team to transform the data in a way specific to the needs of the application being built and maintain a data pipeline to process map updates at the desired frequency – including infrastructure considerations. Essentially, this requires the building of a mapping solution around the mapping data itself.

API’s leverage existing structures and data to provide mapping with a simple API call. This means that a Map Display, Routing, Traffic, and Search all only require interactions with online queries to be integrated into an application. In doing so, most setup work in regard to maps accessed via the APIs and SDKs would be done in terms of frontend setup: aka, the visual orientation for user on a website, mobile app, etc.

What’s next

In the next article, I’ll go one step deeper into some technical terminology to further describe how Multinet-R’s practical setup differs from the APIs, including exchange formats. This will be an opportunity to understand more about why certain solutions might benefit from each style of mapping, and what those setups look like in more exact terms.

Explore the documentation for our APIs and SDKs on our Dev Portal. Explore our Map Data offerings, and how it powers our other Map Technologies.