The state of mapping APIs for the web in the year 2020

Interactive maps are a common feature for many websites and service channels. Data overlaid on a map helps visitors access location related fast and intuitively. eZ Platform ships with a location field type that enables you to annotate your content items with location data. Using this data as your backbone, your developers and designers are free to use any JavaScript based mapping API to bring location based experiences into life.

With the mapping API market market having matured in the past years, it's a now good time to take some time to consider the available options for creating user experiences that rely on maps. In this article we will examine some of the approaches available on the market today, and weigh in on their pros and cons. Please note that is not relevant only for solutions built with eZ Platform, but any service that relies heavily on maps in the browser.

A brief history of maps on the web

Maps have been around for a thousands of years, and they've also been a vital part of the web ever since its dawn in the early 1990s. The early mapping solutions like MapQuest, the first commercial online map service that launched in 1996, were very elementary and were cumbersome to use. But despite their shortcomings, they did provide so much value that many professionals used them, even if they sometimes felt like sleeping on a bed of nails.

The technology that broke maps to the mainstream web was Google Maps. It launched in February 2005 and used novel technology to provide a great user experience. This and the ability for developers to use the map on their own sites meant that that Google Maps became synonymous with online maps. The Web 2.0 hype was largely fueled by Google Maps based "mashups". it is still likely the most widely used mapping platform, which has continued to evolve with improvements like removing clouds from satellite imagery.

Initially Google had a technical advantage over its competition, and it is still ahead certain areas like 3D visualization. But for laying down data on a top-down map Google Maps no longer stands out the way it did ten or fifteen years ago. Nowadays there are a number of different options for creating interactive map experiences on the web. Some globally recognized alternatives to Google Maps API are Here, MapKit from Apple, Microsoft's Bing Maps API, TomTom and Yandex Maps, but there are countless other options out there.

In the early days many mapping web APIs were free and easy to deploy. Commercial licensing options have always existed for use with business systems, but for the longest time maps were easy and free to use on public websites (with modest traffic). This changed in 2018 when Google announced Google Maps Platform and a new pricing model:

Beginning June 11 [2018], you'll need a valid API key and a Google Cloud Platform billing account to access our core products. Once you enable billing, you will gain access to your $200 of free monthly usage to use for our Maps, Routes, and Places products.
- Introducing Google Maps Platform

This meant that now everyone looking to use Google Maps on their site would need to enter their credit card details. The included $200 in free credits each month goes a long way for small to medium sites, but it can definitely be a pricing shock for large scale online services often built with the eZ Platform DXP, such as large retail chains who would like to offer driving directions to their store locations to make their customers' lives easier.

Building and maintaining quality maps and related infrastructure is not cheap. This is why virtually all commercial mapping API services feature only a limited free tier. This is why your online budget needs to include funds not only for hosting, but mapping services too.

There's no such thing as free lunch…

…or is there? As discussed in the previous paragraph, it is fair that companies will want to monetize their investment to mapping technology. Does this mean we can't ever get free mapping APIs anymore? Not necessarily. OpenStreetMap (OSM) is a community driven collaborative mapping platform that is ran by a non-profit foundation. The foundation gets funding from membership fees as well as donations to develop the technology platform.

Compared to tech giants the foundation's resources are limited, but the key difference that allows them to compete with the trillion dollar behemoths is that OpenStreetMap map data is generated and curated by volunteers, similar to content on Wikipedia. Map data can also be imported from open data made available by public sector operators. An example of this is the effort to import data from National Land Survey of Finland to OpenStreetMap.

OSM has been embraced not only by individuals and small businesses, but corporations as well. Companies without their own mapping services are contributing to the project as corporate members. In addition to funding they can push the project forward with software contributions. A great example of this is Facebook bringing their Artificial Intelligence (AI) know-how to OpenStreetMap with RapiD, a tool that allows accelerating map creation:

We used this system [RapiD] to map all the previously unmapped roads in Thailand - more than 300,000 miles' worth - in OpenStreetMap (OSM), a community-based effort to create freely available, editable maps of the world. We were able to complete this project in 18 months - less than half the time it would have taken a team of 100 mapping experts to do it manually.
- Mapping roads through deep learning and weakly supervised training

Even with funding and corporate participation like the one from Facebook, the OSM project would not be sustainable as a Google Maps Platform or Bing Maps competitor. This is because in addition to providing the technology and data, there are huge resource demands for storing and delivering it to millions of clients around the world. When choosing to go with OpenStreetMap you might need to carry some of that weight yourself.

One size does not fit all

After reading the previous section it might seem like going for OpenStreetMap is a no-brainer and only a fool would go for anything else. But this is certainly not the case, and there is room for many players in this field. For many a free tier of Google Maps can be the best solution: Allow quick time to market without ever costing a cent. But a national real estate portal using maps as their primary interface might find the cost to be prohibitive.

While OSM and its data is free to use, you might need factor in additional hosting cost for it. For large scale OpenStreetMap deployments you're expected to host your own map data - this is known as running a tile server. There are tools like OpenMapTiles.com to help you, but this this still adds complexity and increases running costs. If you've got a DevOps team in place running a myriad of services on AWS, adding one more (rather simple) service might not be a big deal. But for a business doing their hosting on a PaaS like eZ Platform Cloud, it might be cheaper to pay a commercial API vendor each month and be done with it.

Sometimes the choice between different mapping providers can also be driven by business decisions. In large organizations you might benefit from consolidating services to specific suppliers. For example, a logistics company with a back-office fleet tracking system using Bing Maps might be able to get a good price for using the same provider for maps in their customer facing digital service channel. Development and maintenance cost could also be lower in the long run if the same team (or teams) would be working on both systems.

Another thing to consider is the geographical region you're targeting. In some ares Yandex Maps data might be superior to OpenStreetMap making it the better option, even if the cost would be higher. Most mapping API vendors also offer additional features such as driving directions or reverse geocoding capabilities, but OpenStreetMap only provides maps. You can integrate additional tools to enable driving directions with Valhalla routing engine, but hosting and development cost would be higher than if you went with the Here routing API.

There is also something of a hybrid between commercial and community driven mapping solutions. Service providers like Mapzen and Mapbox make adoption of OpenStreetMap easier by providing transparent map tile hosting, readymade UI components and features like MapBox Studio to allow building custom interfaces as low-code effort. Mapzen on the other hand integrates with Valhalla to provide turn-key turn-by-turn navigation. Like purely commercial offerings these providers have a free tier, but with higher usage costs escalate.

Plan for change, use an abstraction layer

So, there is definitely no single mapping solution that would be ideal for every situation. With the variety of options available today, you should prepare to change mapping vendors more than you probably did in the era when Google Maps was the de-facto standard.

Our Open Source DXP, eZ Platform used Google Maps until version 2.0. There was no issue with the technology, but the licensing change was troublesome. From June 2018 onwards those who would like to use our system would need to create a Google Payment Account, just to use our open source platform. Today we are using OpenStreetMap which is suitable for us, but If we chose to package eZ Platform as a SaaS then that might not be the case.

Deeply integrating to a single mapping API leaves you vulnerable to pricing, feature and API changes in the future. In addition, the cost of a rewrite might make it prohibitive to change. This is something purveyors of Open Source Software often like to call a vendor lock. To allow flexibility to switch between mapping APIs, you should consider using an abstraction layer that allows switching map providers without a costly rework of your application.

The most common map abstractions for the web are Leaflet and OpenLayers. Both of them are JavaScript libraries that allow to write your application against their APIs. This makes switching between different map providers a matter of configuration, rather than a complete rewrite. In reality complex integrations will require some code rework, but the core functionalities like initializing maps, setting points will be handled by the abstraction.

The purpose of this article was to give you an idea of the different options you've got to build implementations. Whether or not you remember the details does not matter, as the key takeaway is that choosing a mapping provider and implementation is a strategic choice that you should take into consideration from the very beginning of your project.

Next week we continue with maps with a more practical take: A hands-on tutorial on how to create a simple store locator feature with eZ Platform, OpenStreetMap and Leaflet. In the meantime you'd like to talk to me or one of our experts about your mapping requirements please fill out our contact us form or email me directly developeradvocate@ez.no.