Vector tiles have become industry standard in interactive maps that, unlike openstreetmap.org, don’t get updated often, and where you can simply recalculate your whole database occasionally.

But the map displayed on openstreetmap.org are quite uniquely different! They get updated incrementally and constantly, a minute after you edit; it’s a critical part of the feedback loop to mappers—and how the author of this blog post got hooked in the first place. This is why we have to invest in our own vector tile software stack.

The switch to vector tiles, the post goes on to say, will enable all sorts of dynamic changes to the map: “3d maps, more efficient data mixing and matching and integration of other datasets, thematic styles, multilingual maps, different views for administrative boundaries, interactive points of interest, more accessible maps for vision-impaired users, and I’m sure many other ideas that no one has come up with yet.”

Update, 3 Feb 2023: Tom Tom is running with Killick’s take.

Multiple datasets reference the same real-world entities using their own conventions and vocabulary, which can make them difficult to combine. Map data is vulnerable to errors and inconsistencies. Open map data can also lack the structure needed to easily build commercial map products and services on top.

Making it easier to combine data—one of Overture’s aims is to create “a common, structured, and documented data schema”—sounds an awful lot like a way to address James Killick’s complaint about the geospatial industry’s lack of common data standards (previously). It also sounds like TomTom’s map platform, announced last month, is part of something bigger.

Given the talk about open map data, it’s not surprising that the OpenStreetMap team has some thoughts about the announcement, and about how Overture and OSM might work together in the future.

Basically, TomTom is building a map ecosystem that can be built on by developers and businesses: an apparent shot across the bow at the Google Maps ecosystem. And indeed that’s how The Next Web sees it: an attempt to “wrestle control” of digital mapping away from Silicon Valley.

TomTom plans to do so by combining map data from its own data, third-party sources, sensor data, and OpenStreetMap. I’ve been around long enough to know that combining disparate map data sources is neither trivial nor easy. It’s also very labour intensive. TomTom says they’ll be using AI and machine learning to automate that process. It’ll be a real accomplishment if they can make it work. It may actually be a very big deal. I suspect it may also be the only way to make this platform remotely any good and financially viable at the same time.

A map showing the lighthouses of Europe has gone viral on social media. It’s a Geodienst project that actually dates back to 2017 or so. The map is generated using lighthouse data extracted from OpenStreetMap. “More specifically, it asks the Overpass API for all elements with an seamark:light:sequence attribute, decodes these, and displays them as coloured circles on the map using Leaflet. It also tries to take the seamark:light:range and seamark:light:colour into account.” (The above animation, taken from the project’s GitHub page, doesn’t show colours, but maps can be built that do, and the example going viral does.)

Previously: OpenStreetMap at the Crossroads; OpenStreetMap ‘In Serious Trouble’.

What Facebook fail to state is the inaccurate manner in which their AI mapping worked. The OSM community in Thailand had for years, been working slowly on mapping the Country, with the aim of producing a free to use and accurate map for any user. Information was added backed by a strong local knowledge, which resulted in a usable GPS navigation system based on OSM data. Main road were main roads, and jungle tracks were tracks.

Then along came Facebook with its unlimited resources and steamrollered a project in Thailand with scant regard for contributors … sure they paid lip service to us, with offers of collaboration, and contact emails … but in reality, all our comments went unanswered, or simply ignored.

Sure, their imagery identified roads we had not plotted, but along with that came the irrigation ditches, the tracks though rice paddies, driveways to private houses, and in once case, an airport runway! All went on the map as “residential roads”, leaving any GPS system free to route the user on a physical challenge to make it to their destination.

Local users commented, but the geeky humans who were checking the AI, living thousands of miles away, having never visited Thailand, just ignored our comments. They would soon move onto bigger and better things, while sticking this “success” down on their resume.

Sounds like another case of local mapping vs. armchair mapping and automated edits, where local mappers are swamped and discouraged by edits from elsewhere. [Florian Ledermann]

Previously: OpenStreetMap at the Crossroads.

The problem was traced to OpenStreetMap, one of Mapbox’s data sources. On August 10 an OSM user renamed a number of New York landmarks, as well as New York itself, after a number of alt-right and neo-Nazi memes. The edits were quickly reverted and the user blocked—on OpenStreetMap. They nevertheless entered the Mapbox review pipeline, where they were, in fact, caught and flagged on the 16th, but a human editor mistakenly okayed the renaming of New York to Jewtropolis. A simple human error, but with a delayed fuse: the edit turned up on Mapbox’s public map two weeks later. When all hell broke loose on the 30th, the map was fixed within a few hours.

Vandalism of online maps isn’t a new thing: in 2015 Google ran into trouble when a series of juvenile map edits exposed the shortcomings of the Map Maker program’s moderation system and led to a temporary suspension of Map Maker (it closed for good in 2017) and an apology from Google. Anything involving user contributions needs a moderation system, and OpenStreetMap and Mapbox both have them. But moderation systems can and do still fail from time to time. (That’s a take on this incident that isn’t on Bill Morris’s list.)

Traffic. Traffic congestion is a key feature of mobile mapping, and predicting it involves looking at historical data. CityLab reports on a recent study suggests that time-of-day electricity usage patterns can be used to predict traffic congestion patterns. A household that starts using power earlier in the morning gets up earlier and presumably will go to work earlier.) It’s another variable that can be put to use in traffic modelling.

Trail difficulty. OpenStreetMap doesn’t differentiate between “walk-in-the-park” trails and mountaineering routes, and that may have had something to do with hikers needing to be rescued from the side of a British Columbia mountain recently. The hikers apparently used OSM on a mobile phone app, and in OSM trail difficulty is an optional tag. The wisdom of using OSM in safety-critical environments notwithstanding, this is something that OSM editors need to get on. [Ian Dees]

When it comes to increasing access to health services, safety, and education—things women in many developing countries disproportionately lack—equitable cartographic representation matters. It’s the people who make the map who shape what shows up. On OSM, buildings aren’t just identified as buildings; they’re “tagged” with specifics according to mappers’ and editors’ preferences. “If two to five percent of our mappers are women, that means only a subset of that get[s] to decide what tags are important, and what tags get our attention,” said Levine.

Sports arenas? Lots of those. Strip clubs? Cities contain multitudes. Bars? More than one could possibly comprehend.

Meanwhile, childcare centers, health clinics, abortion clinics, and specialty clinics that deal with women’s health are vastly underrepresented. In 2011, the OSM community rejected an appeal to add the “childcare” tag at all. It was finally approved in 2013, and in the time since, it’s been used more than 12,000 times.

Interestingly, when you look at crisis mappers, the female participation rate jumps: to 27 percent, based on a survey of the Humanitarian OpenStreetMap Team community.

Before I criticize the project, I want to state emphatically that I still believe wholeheartedly in the core principles of OpenStreetMap. We need a Free as in Freedom geographic dataset just as much today as we did in the past. When I wrote my article about OSM in 2012, self-driving cars and other services were still a dream. Today the importance of having a highly accurate, libre geographic dataset is more important than ever, and I support those working to make it happen.

That said, while I still believe in the goals of OpenStreetMap, I feel the OpenStreetMap project is currently unable to fulfill that mission due to poor technical decisions, poor political decisions, and a general malaise in the project. I’m going to outline in this article what I think OpenStreetMap has gotten wrong. It’s entirely possible that OSM will reform and address the impediments to its success—and I hope it does. We need a Free as in Freedom geographic dataset.

I do love me a good rant; and as an OSM contributor myself, I do recognize some of the problems Serge highlights, particularly the difficulties in importing data, moderating edits, and vandalism.

Since getting linked there is what drew attention to it, Hacker News comments (I know, I know) are here.

Previously: OpenStreetMap at the Crossroads.

Previously: Volunteers Mapping Post-Hurricane Puerto Rico.

Today Esri is proud to announce that we are making our own global collection of satellite imagery available to the OSM community directly through our existing World Imagery Service. This regularly updated resource provides one meter or better satellite and aerial photography in many parts of the world, 15m TerraColor imagery at small and mid-scales (~1:591M down to ~1:72k), 2.5m SPOT Imagery (~1:288k to ~1:72k), 1 meter or better NAIP in the US and many other curated sources, so we know it will make a welcome addition to OSM’s growing catalog of reference layers.

OSM editors have been able to trace maps from satellite imagery for years; other sources of such imagery have included Bing and Yahoo (back when Yahoo Maps was a thing). Different sources have different strengths, so this can only help the project. (Esri’s imagery makes no difference where I am, but that’s not a surprise.)

Martijn van Exel’s OSM Then and Now compares OpenStreetMap as it was in October 2007 with how it is today, with a slider to change how much you see of one or the other. Amazing how little was mapped back then, especially outside: my own town didn’t appear at all, and even Ottawa was rudimentary.

Start with the National Hurricane Center, which has lots of different maps of Hurricane Matthew’s predicted path, weather warnings, rainfall potential and so forth. See also maps from Weather Underground.

Google’s Crisis Map includes evacuation resources—Red Cross shelters, evacuation routes, traffic data—in addition to storm track and precipitation information.

Matthew has already struck southwest Haiti; the Humanitarian OSM Team has put out a call for crisis mappers on the following projects: buildings in Nippes; road network in Grand’Anse and Sud.

Wind maps from Windytv and EarthWindMap visualize the wind patterns of Matthew and, further out in the Atlantic, Nicole.

Hurricane imagery from NOAA’s GOES East satellite. NASA Earth Observatory has imagery of Matthew’s path toward Florida.

[Dave Smith/Maps Mania/NASA Earth/NOAA Satellites]

I heard much frustration from crisis mappers about the craft-style focus of the international State Of The Map conference in Brussels later this year, while the hostility of the public OSM-Talk mailing list to newcomers of any kind has been a running joke for a decade. The robot mappers show up for conferences but engage in a limited way dictated by the demands of their jobs. Craft mapping remains the heart of the project, potentially due to a passive Foundation board who’ve let outdated behaviors go unexamined.

Naturally such pot-stirring did not go unnoticed (see the comments in Michal’s post).

It’s probably not helpful to pit one group of users against another. Each group is contributing to the map for their own purposes (some of which, it must be said, are commercial and self-interested), but they all have the same goal in mind: a good, usable map. It’s how they get there—and why they want to get there—that’s at issue.

Both craft and crisis mapping can fail to see the forest for the trees: both depend on the efforts of a motivated cadre of mappers, whether they’re local hobbyists trying to improve the map of their own community, or mappers trying to help disaster relief efforts. But relying on those efforts can lead to a map of wildly uneven quality. As I wrote in “All Online Maps Suck,” my 2013 piece on online map quality,

The problem with OSM is also its strength: it’s entirely dependent on the attention of volunteers. Where there are a lot of volunteers, the map is invariably excellent. But where there aren’t any volunteers, the map is empty.

Automated edits are the opposite of the above. When based on existing databases (CanVec in Canada, TIGER in the United States), they represent top-down mapping rather than from the bottom up, which goes against the original sensibilities of OSM. But they can cover a lot of ground that would otherwise go unmapped, or mapped in only the most cursory way.

The problem is when the different mapping methods come into conflict. It’s extremely easy to step on one another’s toes. Local mapping efforts can be discouraged by armchair mapping (which I have to confess I’ve done rather a lot of—even crisis mapping can privilege foreign computer users over on-the-ground mapping) and automated edits that can overwrite individuals’ work if not handled carefully.

Responding to Michal’s post, Tom Lee identifies another constituency that Michal missed: “passive users of OpenStreetMap data. Naturally I am thinking of Mapbox customers, but also people using MapQuest and Mapzen and Carto and Maps.me and countless other businesses.” Note the words customers and businesses—not just map users. Regardless of its original ethos, OSM data supports a lot of for-profit businesses. Tom puts his finger on it: there’s a dichotomy between mapping as a hobby and mapping as part of the job.

For end users, the politics of OpenStreetMap ought to be so much inside baseball. My own concern, as a heavy OSM contributor over the years (which is to say, a “local craft mapper”), has been less about how the map was made than whether the end result was a good map. I worried a lot that my edits would get someone else into trouble, or that the incomplete map would be put to use—by those “passive users” of OSM data—before it was ready, for political or economic reasons. The voracious hunger for open mapping data was what worried me—and it’s what’s driving the conflict in this case.

(Comments are open, because I expect I’m wrong in some of the particulars.)

Adding Pokémon Go gym locations to OpenStreetMap is a no-no, by the way. [James Fee]

CanVec is a dataset produced by the federal Department of Natural Resources. It’s been made available to use in OpenStreetMap: users have to download the data for a given area and import it into the OSM database.

It’s a great resource, but I’ve been giving CanVec the side eye for years, largely because OSM users had been bungling the imports and not cleaning up the mess they made. To some extent it also encouraged a certain amount of laziness from Canadian OSM users: why go to the trouble of tracing imagery or going out with a GPS if you could just download the data from the Natural Resources FTP server?

That said, most of my complaints were from a few years ago; it’s been a while since I’ve seen a CanVec-induced mess in the database (for example, doubled or even tripled roads imported on top of one another). And between existing imports and the improved Bing aerial and satellite imagery coverage, there weren’t many places I was aware of that I could, you know, try a CanVec import for myself.

Except one.

Hartney, a town of a few hundred people in southwestern Manitoba, managed to fall between the cracks of two swaths of aerial and satellite imagery. It was a noticeably empty patch of a map that was starting to fill up.

It was also the town my father grew up in. I spent a lot of time there as a child. I was, suffice to say, familiar with it. It was therefore a natural target for me to map. But with no imagery and no realistic chance of my visiting there in the near future, I was not likely to do so in the usual manner.

So I imported CanVec data.

It turned out to be a lot easier than I expected. For one thing, I didn’t have to import the entire tile: I could import only the items I wanted. For another, I didn’t have to resort to JOSM or some other application I was unfamiliar with; I could, it turned out, do it in Potlach, the Flash-based web editor I’ve always used, by importing the downloaded zip file as a vector layer and alt-clicking each element through into the edit screen.

But easier still wasn’t objectively easy. I had to figure out what file to download from the FTP server by looking it up on the Atlas of Canada, and figuring out which of the files to import into Potlatch is a bit of a trial-and-error thing. There’s also a bit of a delay before the CanVec layer shows up in your edit window.

In the end, though, I was able to figure it out, with the following results:

I practiced good edit hygiene: I created a separate user account for imports (here) and I cleaned up what I edited: I joined road segments so that a road five blocks long wasn’t five separate ways, I straightened a badly garbled stretch of rail line, and I added a couple of points of interest I knew from personal experience.

In the end, I think I’ve left the map better than I found it. I didn’t add everything I could have: CanVec isn’t perfect, and I’m not in a position to verify its data on the ground, so I adopted a less-is-more approach, so that I didn’t simply add a ton of data for someone else to clean up. Nor did I add so much that it would discourage a local user from adding more, better, and more up-to-date material.

A positive experience overall. I was surprised.

You’ll recall that there were a lot of complaints about Apple’s maps app when it launched with iOS 6, replacing the previous app that was powered by Google Maps. The map data didn’t match the user experience: it was a first-rate app that used second-rate data. Apple oversold the experience and failed to meet the high expectations of its customers. It was a problem that no other online map provider had ever had to deal with before, not least because no one had launched a new map service with the same amount of hubris, nor the same amount of scrutiny from day one.

But many of the complaints about Apple’s maps verged into hyperbole. The notion that Apple’s maps were uniquely bad compared to other online maps was frankly unfair. Because when you get right down to it, all online maps suck. They all fail in some way, somewhere, and some more than others—and if the maps you use seem fine to you, it’s because they suck somewhere else.

Apple, after all, didn’t invent map errors. Map errors have a long history; I’ve catalogued dozens of them over the years. Maps got people lost long before iPhones sent people into dangerous regions of Australia; satnavs’ blithe directions have been leading credulous drivers into bridle paths, ditches and railways for as long as there have been satnavs. There is no such thing as an error-free map. And the alternatives have their share of them.

Take Google Maps. By the time Apple booted it off the iPhone, Google Maps had become the gold standard of online maps. Deservedly so: Google had spent considerable resources getting them to that standard (and not inconsiderable resources telling us how much they had worked on those maps). Not for nothing were people demanding its return to iOS.

The thing is, Google’s maps weren’t always good. Google’s maps have a long history of sucking from time to time. But people have short memories, or haven’t been paying attention. Google was fixing its mistakes when most web map users were still using Mapquest, most drivers were using satnavs from Garmin and TomTom, and most people didn’t have smartphones.

Some of Apple’s map errors had a familiar ring to them. The warped 3D images ridiculed in Apple maps—a function of two-dimensional satellite and aerial imagery being applied to three-dimensional terrain—were a long-established feature of Google Earth. And Google ran into all kinds of trouble when it began replacing map data from Navteq and Tele Atlas with its own data in 2009—the same map data it touted so much last year. There were errors all over the place. The change was called premature and “a significant step down in quality.” But even before that, when Google switched from Navteq to Tele Atlas in 2008, I unearthed all kinds of new errors in my neighbourhood; switching to its own data a year and a half later fixed many of those errors but created new ones.

In hindsight, you can see Google’s business logic: switching to its own mapping data, rather than relying on maps provided by companies with competing interests, like Nokia (who owns Navteq) or TomTom (who owns Tele Atlas), carried significant strategic advantages that outweighed the short-term hit to its map quality.

Building your own maps in order to avoid relying on a competitor: now where have I heard that before?

Moving along. What about OpenStreetMap? At its best, OSM can be better than any other online map. At least that’s what its proponents say, citing an example like some zoo in Germany as an example of how good open source mapping can get. And, like Google, they have a point. OSM can be pretty good. I’m a heavy contributor to it, so I have a dog in this hunt: I want it to get really good.

But at its worst, it’s the worst online map there is.

For example, last week I spent a surprising amount of time adding highways, rail lines, towns and even lakes in central Saskatchewan, an area of surprising emptiness in OSM even though there is lots of high-resolution imagery to trace (to say nothing of CanVec data available for importing). I couldn’t do much more than lay down the grid and guess at some of the land uses (churches, schools and retail and commercial areas can usually be figured out from imagery, names can’t), but while I left the map in better shape than I found it, there are still hundreds of person-hours of work left to do in that area.

The problem with OSM is also its strength: it’s entirely dependent on the attention of volunteers. Where there are a lot of volunteers, the map is invariably excellent. But where there aren’t any volunteers, the map is empty. For every Germany there is a Saskatchewan. While OSM is unbeatable in several areas of the world, it’s safe to say that the other online maps have at least acceptable coverage of medium-sized towns in Saskatchewan. Which is to say that OSM is not uniformly good — not yet, not by a long shot.

So couldn’t you use OSM where it’s better than the alternatives? Stitching together map data from disparate sources isn’t exactly easy. Roads and other features might not be perfectly aligned from source to source, and the metadata isn’t necessarily compatible—ask anyone who’s tried to import open government data into OSM how painless a task that is.

A final example. Yesterday I clicked on an address in Facebook for an event in downtown Ottawa. It opened in Microsoft’s Bing Maps, which gave me a location in Greater Sudbury. Why it did so I have no clue, except maybe that Microsoft is being too clever with its IP address detection (my ISP is Sudbury-based). For the record, neither Apple (on my iPhone) nor Google (on the web) had any trouble giving me the right location.

Every map, no matter how good overall, has weaknesses.

This is not new. Paper maps were never free from errors, after all, and with satnavs, even the best onboard maps would become less reliable if you didn’t purchase the updates.

But online maps are different: we’re using them much more often than we ever did paper maps or even satnavs. We haven’t just delegated our navigation skills to them: we’ve integrated them into our maps and websites, we rely on them for transit schedules and business listings. They give us a false sense of security and a false sense of reality: we forget that the map isn’t the territory.

We used to be more tentative with our paper maps or our friends’ directions. We tended to think about it more, rather than blindly follow.

We’ve decided that knowing where to go is no longer our problem, and getting lost is no longer our fault.

This might be a bit premature.

The ability to use other map styles with OpenStreetMap data is, I think, underexploited. I’m starting to hate the default Mapnik tiles. Stamen Design has released three different—vividly different—map styles for OpenStreetmap: watercolour tiles (above), high-contrast black-and-white, and shaded terrain. Via Daring Fireball.

I suppose that I could make the slideshow available if you’re really interested, but my presentations tend to be talks illustrated by slides, rather than read-the-slides, so without me talking it through it’d be kind of confusing. But here’s the penultimate slide, which shows a screencap of OSM’s map of downtown Ottawa, with things that need fixing helpfully labelled.

You’ll be happy to know that many of these things have since been fixed.