We have all been there: when you’ve gotta go, you’ve gotta go. But where? Or maybe you have an infant, and he needs changing. Or maybe you need cash, or maybe you’ve been carrying the empty cup for an hour, walking around (hello South Korea).
Open Google Maps and search for a toilet, and you may find something. It probably is not close by. Below you can see a query from Milan, and it’s trying to tell me that there are only 6 public toilets in the core of the city.
Of course, many more show up on OpenStreetMap:
Yes sure, “OpenStreetMap is better”, the usual. Personally, I always use Organic Maps app to find a nearby toilet in Switzerland or the near abroad, and it works very well. In Switzerland the secret is that often the nearest church tends to have a free (gratis) toilet, or maybe the train station (but could be pay-to-use). OSM data reflects this well.
Traveling in Italy, Mexico, or the USA, I have found that I am adding public toilets to the map from time to time. Meanwhile, finding an ATM (bancomat) is also quite a difficult thing. Google Maps again shows a pretty limited number in Milan:
And again, more luck with OSM, but certainly this cannot be all the data:
ATMs and toilets are two things that certainly matter to a tourist, so it is a familiar search for me in various map apps. These are not the only thing that is so often lacking, however—you could cite a whole class of things that are relevant to pedestrians, or are relevant on a very hyperlocal level.
Authority and the Stream of Map Data
The general body of knowledge that we call “the map” is a lot like other bodies of knowledge we have, as a human civilization. There is medicine, there are dictionaries, there are catalogs of known plant and animal species. Around the world, you might find variations of the consensus, like medicine in India versus medicine in Germany, but they are generally the same and have increasingly converged over the centuries.
Ancient maps were often assembled by copying and conflating other, older maps—leaning on an assumption that the older ones were correct, with locations of things, shapes of coastlines, and so on. When conflicting maps met, the cartographer favored one, with some rationale or randomness. Often new data was added as well—it was a body of knowledge being constantly re-evaluated and evolved.
Today there are “accepted”, popular maps of our urban and rural areas. These are often woven with data from a local authority that gets partially ingested into consumer map apps like Google Maps and databases like OpenStreetMap, where there is some disagreement but a broadly agreeing layout of the world.
There is a stream of map data. The downstream always is a product of something upstream, and the great sea of the internet is where the whole stream ends up, in both fragmented or assembled form.
The upstream part is raw data, but is also made of people—the minds and eyes and experiences that generate observations and measurements and qualitative attributes of locations. The upstream part is additionally made up of agencies, companies, NGOs, meet-ups, clubs, and communities. These are a filtration system that brings raw data through different methods and perspectives to form a downstream map as a user interface, or more data downstream.
Hyperlocality
The bigger a map—the more global, national, regional—the more it can tend to be “top down”. Consumer maps are often the most extreme, like again Google Maps or OpenStreetMap, or Waze, HERE, Esri basemaps, National Geographic, and so on. There is a vision of a product—a map people can use—then the cartography, the data sources, the mediation about which source is truth, all happen from the top down in order to fit into the original overarching vision.
Other maps are hyperlocal—they start in a grassroots way. They sometimes have a purpose, like to map bicycle routes or water sources or recycling points in a community. Sometimes they are commissioned by local government as a form of asset management, sometimes by a local club as a way of storing and sharing knowledge.
These hyperlocal maps tend to also be what might be called “craft mapping”, and to keep a reference to brewing beer and distilling spirits going, could also be called “small batch”. Like an artisanal cheese, they are difficult to scale for mass production, because so much finesse goes into them. They are extremely detailed in the precision and descriptiveness of their contents, and generally are a linear process. If 100 people gather to map city parks in great detail in Rome, you can probably guess that 100 will be needed to do the same in Buenos Aires.
OpenStreetMap benefits from having these hyperlocal efforts, where people map what matters to them, without trying to make sure it aligns with a global goal of OpenStreetMap that is too specific (OSM does not have such goals). Meanwhile, TomTom aligns with a subsegment of OSM community—the group that shares the company’s interest in having top quality road data. An outdoor recreation app like Whympr overlaps with a different subsegment of OSM, which cares about mapping paths, trails, and physical geography.
Google Maps will often have poor data in ultra-specialized cases, outside of the specialties they rely on for business (mainly road for driving, POIs, and things needed for geocoding and search). Check out a ski resort on Google Maps, or a golf course, or a remote area in Kyrgyzstan, and you will often find glaring errors and omissions. The omissions make sense—data wasn’t gathered because it doesn’t fit the organizational key goals—but the errors are a byproduct of this as well, where a lack of hyperlocality results in accepting something on the map in lieu of nothing.
“Giving someone no map is much, much better than giving him a wrong map,” wrote Nassim Nicholas Taleb.
A Division of Labor
In the case of SwissTopo, the source data is the national infrastructure and geography of Switzerland. The app condenses this to show power lines, tunnels, cliffs, public transit stops, hiking paths, ski routes, mountain huts, and more. There is a big funnel of data the Swiss government collects, at federal, cantonal, and municipal level, and then filters and transformations to end up in a consumer app for outdoor recreation.
With Google Maps the app began with some amount of open data, like TIGER roads in the US (we are talking about the vector maps, not Google Earth, but this is similar). When public domain and open data were exhausted, Google began sourcing data collection, or buying existing closed data or companies, or doing some in house generation of data like extracting vector geometry from aerial and satellite imagery.
Later, Google would acquire a company doing street view collection in Switzerland, as part of an effort to own its own data pipelines all the way to the field collection source.
A general pattern here is that Google has generally owned the entire vertical of its maps—the interface users see, the street view, the generation of vector basemap data, the points of interest, the routing engine, the search mechanisms, and more.
This is a big contrast to most other large companies, which often use some combination of OpenStreetMap, government open data, crowdsourced inputs, maybe even Wikipedia as an augmented source about POIs. Overture Maps Foundation represents a further step away from the Google model of a fully vertical map stack, and Overture/OSM users can use MapLibre to style and display the map.
The Overton Window of Maps
It is rare, overall, that the consumer app and the data source are both controlled by the same entity, and aligned toward the same purpose. Any OpenStreetMap app, like Organic Maps, does not have somewhere in it's hierarchy the same executive as OpenStreetMap. It has contributors in common, but a very loose affiliation. Some apps like GeoVelo only focus on cycling, so transform OSM data to that purpose.
The opportunity for these apps is that various kinds of speciality tools can spin out of OpenStreetMap, if the data type they need is there. OpenCycleMap, OpenSnowMap, maps of driveways for Amazon logistics, maps of historical and cultural sites in Italy, all can stem from OSM because OSM is itself a crowdsourcing platform and global database.
Google meanwhile, even though it now crowdsources data and encourages Local Guides to improve data quality, still has a far more narrow purpose and therefore does not return much map data outside the “Overton Window” of what should be in a consumer map app.
Any super specialized data type can probably go onto OSM but also requires probably a super specialized app to properly search, view, and interact with that data. But it is possible!
Google Maps is still the norm though—things like power lines or defibrillators being in OSM are more of a quirk, a small tangent from otherwise being a quasi-clone of Google Maps.
Overfitting
Google Maps is becoming an example of “overfitting” of a model of mapping—the data is curated exclusively to improve and reinforce the user experience of the mobile app. This is not only perfectly acceptable for Google Maps, but in fact is excellent product management, with a focus on continuing to give users what they seem to want and doing only a little experimentation with new things.
The new things in Google Maps tend to get complaints anyway, like fuel optimized routes or immersive view that has little utility. Google Maps is mostly a mature product that can best serve its users by simply doing more of the same.
There is little new territory to discover, little room for innovation, in the world of consumer maps for mobile phones. The biggest opportunity is in building alternatives to Google Maps, or unbundling its features.
Decluttering the Map
Many sort of micro-level features are simply ignored when deploying a global map. I made some effort to add more OpenStreetMap feature classes to the OpenMapTiles schema, but these proposals have been stuck and never ingested. Parking lots aren't displayed as polygons still—only as a “P” on the centroid, as a point—and things like trees or benches do not appear. The intention is to save space in map tiles.
Google Maps has completely set the expectation here, and OpenStreetMap data has been throttled in the libraries that make it most available because in the end the use case for consumer maps generally has categories that are essential and non-essential. It does make sense, although I argue OpenMapTiles users should have the option to show everything and can have a default setting that compiles tiles without the small details, like it is now.
The apps that use map tiles like this also do not tend to have a zoom level that is very close—18-22 is the max, often more toward 18. If you don't know what that means, let's just say that like Google Maps, you cannot zoom in much closer than viewing a city block on your mobile phone screens as opposed to viewing a single street corner.
Hyperlocal maps probably merit a new way of viewing maps. In Google Earth and Google Maps satellite view on the laptop, when you scroll your mouse wheel rapidly and zoom into the map too closely in an urban area, the scene automatically morphs into Google Street View. Suddenly, you are no longer looking at a map as you normally think, but instead you are inside the map—your virtual feet are on the ground in street view.
When you do use Google Maps for navigation on foot, you still are using the same user interface that someone used when driving a car and navigating with the phone. The map shows you very little about what is within 10 steps of you, and a look about what is 100 meters away.
Of course, Augmented Reality (AR) is emerging, like in Google Maps Live View, as a way of viewing hyperlocal data. But it's a terrible experience through a phone screen, and there is no mass adoption of futuristic glasses happening this week. Many people already spend a huge amount of time looking at their phone screens, although perhaps with some angst, and generally don't mind using their phone for maps. But the reaction feels widely negative toward pointing your phone camera to see what's around you when you have eyes in your head.
Is there another way that hyperlocal data could be viewed through the phone, both avoiding the birds eye view that is appropriate for road centerline, higher speed travel, and the awkwardness of using a phone camera as a monocle?
The Medium Begets the Data
If there was a pleasing way to interact with maps on a 10 meter scale, then the demand for more hyperlocal data like steps, ATMs, fountains, toilets, mailboxes, vending machines, even electrical outlets, doorways, and benches, would likely grow. Before mobile phones, a lot of map data also did not exist—a POI was an entry in the Yellow Pages, rather than a sort of baseball card of information and even reviews and photos of a business. `
For now, we are stuck in some design rut analogous to POIs being stuck in a phone book. We are completely conditioned to maps being a birds eye view experience, that sometimes allows for a little tilting and of course supports zooming and panning. The map is flat, even if we can garner likes and shared by showing it in 3d, or on a curved surface. The overview of the world needed to plan a construction project or a road trip has been co-opted to be the model we use to understand what is around us.
The paper map has gone digital and interactive, but on a hyperlocal level our maps are just completely different than the way our brains perceive and navigate space as pedestrians. There is some puzzle to be solved here. There is something about how maps tell us to navigate that we do need—a mathematical calculation really—but that forces us to look at the map of our local environment as a series of routes in a network, with some context about what's adjacent to the edges.
Rather than the map being like a digital lake we can swim through, it is a digital circuit breaker that we are constrained within, bound to the lines. There is very little concept of moving left/right, up/down, almost only a 1 dimensional ability to interact, to go only further or backward on a linear route.
The lack of ability to break out of this view of the world drives a lack of data. Much of the what is incredibly obvious to our naked eyes is invisible on the digital map, and unfindable without being there.
No Map is Better than a Wrong Map
Perhaps in the end, we don't even need to map these things—rather than searching a database, where someone already found the location and indexed it for us, we must accept that every time we look for the toilet while visiting a busy new city, part of the adventure is always frantically having to find it yourself for the very first time, and letting the next person enjoy the same journey.
I will follow up this post with two more, to make a voyage into the imagination—to answer the question of how we could see the map differently:
The Hyperlocal Map Interface
Map Tools for Mars
Watch this space as always for the next installments!
I enjoy Christopher's writing. It is good to get away from the detail of keeping OSM running and to explore the what-if and future possibilities of the platform and project. There is so much more OSM could offer if we had the funds and the volunteers - it is exciting to let our imagination fly. And fortunately I think it is that very imagination of wonderful things that can catch the imagination of donors and volunteers.