Tag: OpenStreetMap

The Rationale Behind Overture

Published on by Jonathan Crowe

A couple of links regarding the Overture Map Foundation announcement (previously) afford some context and background. James Killick chalks up the decision to launch Overture to a combination of needs to control costs and maintain control while ensuring interoperability: “the reasons for the birth of OMF seem to be valid and defensible.” Meanwhile, the Geomob Podcast interviews geospatial veteran Marc Prioleau, in which (among other things) Marc observes that the companies behind Overture (including Meta, where he’s currently at) and OpenStreetMap are not on the same page: OSM’s focus does not serve the companies’ needs, and changing that focus would harm the OSM community. (Since “why not just use OpenStreetMap?” is a recurring question.)

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

The Overture Map Foundation

Published on by Jonathan Crowe

Announced earlier this month, the Overture Map Foundation is an initiative founded by Amazon Web Services (AWS), Meta (i.e. Facebook), Microsoft and TomTom to build an ecosystem of interoperable open map data—an ecosystem, note, that does not at the moment include Apple, Esri or Google, so presumably this is a way for smaller owners of map data (at least for TomTom values of smaller) to form Voltron punch above their weight by making it easier to combine and share resources. From the press release:

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.

The TomTom Maps Platform

Published on by Jonathan Crowe

TomTom corporate logoEarlier this month, at its investor meeting, TomTom announced that it was launching something called the TomTom Maps Platform. The announcement was, because of where it was made, long on investor-focused jargon: growth, innovation, etc., so it’s not immediately clear what it will mean.

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.

The Lighthouse Map

Published on by Jonathan Crowe

Animation of lighthouse beacons in northern Europe

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.)

OpenStreetMap’s ‘Unholy Alliance’

Published on by Jonathan Crowe

OpenStreetMap, says Joe Morrison, “is now at the center of an unholy alliance of the world’s largest and wealthiest technology companies. The most valuable companies in the world are treating OSM as critical infrastructure for some of the most-used software ever written.” Corporate teams, rather local mappers, are now responsible for the majority of edits to the OSM database; Morrison speculates that their participation is about “desperately avoiding the existential conflict of having to pay Google for the privilege of accessing their proprietary map data.” In the end, he argues that we’re in a strange-bedfellows situation where corporate and community interests are aligned. (To which I’d add: for now.) [MetaFilter]

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

Complaints about Facebook’s Automated Edits in Thailand

Published on by Jonathan Crowe

Facebook’s AI tool has added some 480,000 kilometres of previously unmapped roads in Thailand to OpenStreetMap, BBC News reports, but some local mappers have been complaining about the quality of those edits, and the overwriting of existing edits by Facebook’s editors: see OSM Forum threads here and here. In particular, see OSM contributor Russ McD’s rant on the Thai Visa Forum:

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.

Anti-Semitic Map Vandalism Strikes Mapbox

Published on by Jonathan Crowe

An incident of map vandalism roiled the Internet last week. Users of several online services, including CitiBike, Foursquare and SnapChat, discovered that New York City had been relabelled “Jewtropolis” on the services’ maps: see coverage at Gizmodo, Mashable and TechCrunch. The problem was quickly traced to Mapbox, which provides maps to these services. Mapbox, understandably upset about the act of vandalism, soon figured out what the hell happened.

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.)

Google Maps Changes API Pricing, Competitors Respond

Published on by Jonathan Crowe

Earlier this year Google Maps changed the terms of its API and in the process jacked up its prices, leaving web developers to consider other alternatives. These include (among others) OpenStreetMap, which posted a switching guide in June; Apple, which announced its API for websites that same month; and Here Maps, which (a) is still around1 and (b) has announced a freemium plan with reasonably generous transaction limits. As Engadget points out, Google’s trying to profit off its market dominance; its competitors, seeing an opening, are making their move. [Engadget]

A Mobile Mapping Roundup

Published on by Jonathan Crowe

Rerouting. Lifehacker talks about how to prevent mapping apps from rerouting you on the fly, and lists some options. [R. E. Sieber]

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]

OpenStreetMap and Its Women Contributors

Published on by Jonathan Crowe

When I started contributing edits to OpenStreetMap in earnest, I couldn’t help notice certain idiosyncrasies in its tagging: for example, there was a tag for brothels, which I didn’t need to use, but there wasn’t one for daycares, which in Quebec there are rather a lot of. That seemed odd. And it was indicative of a project whose contributors were overwhelmingly male. On CityLab, Sarah Holder examines OSM’s abysmally low female participation rate (only two to five percent of contributors are women), makes the case for better representation, and looks at where women are making a difference to the map. Because a map built overwhelmingly by men can have some massive blind spots.

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.

OpenStreetMap ‘In Serious Trouble’

Published on by Jonathan Crowe

Much chatter on Twitter about a blog post criticizing OpenStreetMap that made it to the front page of Hacker News; problem is, said chatter hasn’t been linking to said blog post. Here it is: “Why OpenStreetMap is in Serious Trouble,” in which Serge Wroclawski argues that OSM has lost its way on a technical and management level:

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.

Esri Makes Satellite Imagery Available to OpenStreetMap Editors

Published on by Jonathan Crowe

Esri is making its satellite imagery collection available to OpenStreetMap editors.

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.)

OSM Then and Now

Published on by Jonathan Crowe
OSM Then and Now (screenshot)

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.