How many web applications or mobile apps do you use that have a map component? Rideshare apps display the location of drivers and passengers; ratings sites show the locations of restaurants; Craigslist and Wikipedia show contextual location for classifieds or encyclopedia articles. High quality, interactive maps are pervasive and simply fade into the background for end users.

The COVID-19 pandemic has created a surge of new mapping applications. Beyond websites that visualize the case count in different regions, maps have become critical computing infrastructure for delivering health services.

For a developer who wants to integrate a map into their application, the choices are almost always to use a hosted, centralized map service; developer map mindshare is dominated by multinational companies. Some hosted map examples:

• The embeddable native maps on Google's Android or Apple's iOS/iPadOS/macOS/watchOS operating systems
• Google's commercial web map offering (Google Maps JavaScript API)
• Microsoft's recent release of Azure Maps and Amazon's AWS Location Service
• Commercial map GIS companies such as ESRI, MapQuest, CloudMade, HERE and Mapbox; free hosted maps like OpenStreetMap Carto or maps by Stamen Design

What is a basemap?

Typical parts of a map application include:

• Translation from search tokens or addresses to locations (geocoding)
• Determining the place name or administrative division of a location (reverse geocoding)
• Finding directions between two locations (routing)
• Overlaying of domain-specific geographic features, such as COVID-19 testing sites
• Showing physical and cultural context on maps, such as city names, nearby points of interest, and roads

It's this last component that we usually call a basemap - especially if it displays map labels, and is zoomable or multi-resolution, implying the application of cartographic generalization.

Single-scale wayfinding maps you see in the real world are labeled and generalized by cartographers; multi-scale basemap services accomplish this in an automated way. The sophistication of computer programs to do this - especially at whole earth scale - can be grossly underestimated, even by experienced programmers. Good labeling and generalization are taken for granted, like good font rendering and typesetting - invisible when successful, glaringly flawed when unsuccessful.

This also illustrates the key difference between a basemap and a dataset of geographic features, such as OpenStreetMap. OSM is not a cartographic product; it does not attempt any generalization or ranking of features. Natural Earth is an example of a cartographic product - it include fields such as scalerank to assist in generalization, curated by human editors.

In theory, basemaps are fungible - the cartographic context required is similar among diverse applications. So why do developers - and as a consequence, the World Wide Web - gravitate towards a small handful of hosted map platforms?

Mapmakers: Victims of Lofty Expectations

The basemap status quo is defined by the cutting edge commercial product, and right now that's Google Maps. Users are accustomed to, and will demand, a seamless abstraction of the physical world. Map panning and zooming should be instantaneous, so designers of a high performance cartographic system must take into account:

• The completeness and quantity of the underlying geodata
• The arrangement and indexing of geodata to achieve low latency
• Tile schemes and partitioning for generalized data
• Protocols for fetching and caching those tiles over the network
• Choice of a rasterization API like Cairo or OpenGL and the flow of vertex data to them

The desired end product is a videogame-like, sixty-frames-per-second experience, and map systems often make the same technical compromises as games: for example, a map system that smoothly resizes labels in real time may choose to precompute signed distance fields for text glyphs on the server and fetch them by codepoint ranges. This works beautifully for languages that use at most a few hundred Latin characters, but navigating to places that use Han characters such as China or Japan will degrade performance. Thus a cartographic system demands holistic design around tradeoffs such as latency or localization capabilities.

Serving Maps: best left to BigCorps?

Given the demanding technical requirements above, it's easy to be led into thinking maps are too hard for individual developers to solve and should be outsourced to a third-party hosted service. A cartographic system is very "full-stack" in nature, but the commoditization of some potential components, like PostGIS or HTTP accelerators, makes the overall task less daunting. Bigness isn't really a constraint; the OpenStreetMap dataset as XML is about 100 gigabytes. Let's estimate 10x expansion to make a cartographic product; that's still only a terabyte of data to put on a disk somewhere.

Developers believe something is too hard, until it isn't. Issuing of SSL Certs was in practice limited to a few Certificate Authorities until Let's Encrypt; Hosting of seekable video content was only done by big sites in concert with CDNs, but now we have the standardized, hardware-accelerated HTML video element and ubiquitous broadband. Email is a notable counterexample; you've been able to run your own Mail Transfer Agent since the beginning, but the Hobbesian underworld of spam and phishing drives users into the oligopoly of a few providers.

Serving maps is hard but not insurmountable; I'll suggest a factor limiting the landscape of web maps is not data bigness or the speed of slinging geodata down tubes, but licensing and realities of the market.

Intellectual Property, Fine Print

Firstly, mapmaking businesses rightly assert copyright over their cartography. This far predates webmaps: Trap Streets are a longstanding practice on print maps. This is often true even if the map is built from open data such as OSM - the derivation of a cartographic product, and quality of output, is "secret sauce" to achieve product differentiation.

Secondly, map serving easily admits a Software-As-A-Service (SaaS) business model. Shrink-wrapped software, or creating a piece of software and "selling it in a box", has been out of vogue for decades, possibly over piracy concerns, or because it has less extractive potential on enterprise budgets. In addition to copyright, Terms of Service for hosted maps often prohibit combination with other geographic services, exclude specific use cases, or forbid caching. These contracts work against developers by inventing scarcity: even if you need a small subset of map tiles, they must be fetched and billed; don't scrape the data and put it in version control.

The freemium, ToS-constrained nature of hosted map services disincentivizes innovation. Inability to swap out the Google Maps frontend means interesting problems like labeling and generalization can't be attacked with piecemeal incrementalism. This tips developer's scales toward Buy rather than Build, especially when the hosted pay-per-hit product starts out free, often as a loss leader for a bundle of geospatial services. These market realities leave some mapping use cases underserved by existing technology.

Map applications ought to outlive the SaaS business lifecycle

Accessing a web map over the network isn't always practical. Maps may need to be displayed on air-gapped internal applications, or work offline without cell tower reception.

Also, websites and mobile applications are often built by organizations separate from their long-term maintainers (e.g. universities, museums, cultural institutions); ambitious visualization projects may be deterred by clients not wanting to foot a pay-per-hit subscription. An application depending on a hosted map service may be permanently disabled if the provider deprecates their API. Hard dependencies on hosted services make software worse - if your data visualization uses Google Maps, don't count on it still working in a couple years.

Developers ought to be able to control their map content

Self-hosted has some generic advantages - less phoning home means better security and privacy. For maps in particular, designers may want to customize the visual appearance of map features, exclude certain layers, or change the language of labels. These are all achievable to some degree with hosted vector map backends and client-side rendering, so DIY maps don't necessarily win here.

A more abstract ideal for DIY maps is control over the underlying geodata. Google Maps data has adjudicated on neighborhood names, administrative boundaries, even the display of particular tourist attractions when zoomed out. Compare to OpenStreetMap: In theory, anyone can edit the map and communities can determine for themselves, say, whether a road's bike lane is sufficiently hazard-free to be highlighted in green. Its availability under an open license (the copyleft ODbL) means developers could exert total control over their maps, even remixing additional datasets into basemaps. Cartographic authority was long ago exercised by governments; commoditization of printing technology transferred this authority to mapmaking and surveying firms; mobile computing has shifted this to Google and Apple Maps. What tools must be built to put mapmaking in the hands of individuals?

I'll be writing more extensively about these topics; to follow along, subscribe via Atom/RSS or email newsletter.

Recommended Further Reading

• A Closer Look with Joe Morrison
• Justin O'Beirne