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.
The New York City government uses Google Maps to help residents find a COVID-19 testing location near them.
The Taiwan government rationed face masks at pharmacies and published inventories via a public API; this enabled citizen developers, in combination with geocoding services and third-party basemaps, to create a variety of web and smartphone applications.
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:
Typical parts of a map application include:
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.
A basemap is most useful for context if it displays map labels. Labels may be in a single language, but might display more than one language, alternate names, or transcriptions: for example, Romaji labels on maps of Japan.
When the map scale is decreased - in this case by a factor of 2 - less relevant geographic features can be removed from the map. The ideal generalization keeps the visual density of the map constant as scale is decreased, even though the number of geographic features existing within those bounds increases exponentially.
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?
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 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.
Mapquest in the early 2000s required the user to click arrow buttons to pan and zoom; maps in 2020 are expected to respond instantly to mouse wheel scroll and finger pinch gestures.
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.
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.
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.
80s.nyc is a streetview-like application for navigating historical images of New York City. It can be useful for discovering lost pictures of your great-grandmother. Depending on a hosted basemap API would expose non-commercial projects to the whims and business models of SaaS providers.
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?
Maps were once so resource-demanding to only be commissioned by emperors. Centuries-old maps are often expressions of state power; white rectangles on the Da Ming Hunyi Tu are paper labels overwriting Chinese placenames with Manchu ones.
Google maps displays "New Zealand", while OpenStreetMap-based maps that default to the name tag display "New Zealand / Aotearoa"
I'll be writing more extensively about these topics; to follow along, subscribe via Atom/RSS or email newsletter.