Tag: OpenStreetMap

More Reactions to ‘Gulf of America’

Published on by Jonathan Crowe

Yesterday’s post looked mainly at Google’s response to Trump’s renaming of Denali and the Gulf of Mexico. Today some news about Apple and OpenStreetMap. On Daring Fireball, John Gruber points to OpenStreetMap forum discussions about the change, which reveals some nuances and complications despite the utter lunacy of the situation. And AppleInsider reports a small change in Apple Maps that may or may not be a placeholder:

If users navigate to the Gulf of Mexico, it still shows the 400-year-old name plain as day.

However, if a user searches “Gulf of America,” the text over the Gulf changes to reflect the search result, but the information sheet shows data and photos about the Gulf of Mexico. This seems to be a working solution that could stick, but there isn’t any word from Apple if that is the plan.

Meanwhile, according to CNN, Mexico’s response to the name change ranges somewhere between dismissive and mocking. The Conversation offers a primer on what goes into changing a U.S. place name.

On the lighter side, Martijn van Exel has created a Gulf of Mexico Watcher that checks whether it’s still being called that. More bitter in tone are the MAGA plugin and the New World Order Google Map, which offer a more … interactive response.

Previously: Naming the Gulf; Google Maps to Use ‘Gulf of America’–Others Not So Much.

OpenStreetMap Is 20 Years Old

Published on by Jonathan Crowe

OpenStreetMap is celebrating its 20th anniversary today. It was originally created in response to restrictive Ordnance Survey licensing in the U.K., in a context that seems unrecognizable today. Founder Steve Coast writes about the anniversary (mirror link). “Allowing volunteers to edit a map in 2004 was simply anathema and bordering on unthinkable. Map data was supposed to be controlled, authorized and carefully managed by a priesthood of managers.”

OpenStreetMap Is Dealing with Some Vandalism

Published on by Jonathan Crowe

It seems OpenStreetMap has had to deal with a wave of vandalism attacks lately. If you see some nonsense on OSM, this post on their community forum outlines what to do about it (it may have already been taken care of even if it’s still appearing, so check for that; also, don’t post screencaps, because propagating the nonsense is what the vandals want). The OSM ops team provided this update on Mastodon today: “OpenStreetMap is now stronger with improved monitoring, automatic blocking, and respectful limits on new accounts. The default osm.org map is now quicker at fixing large-scale vandalism. Offline actions are also progressing.”

Pokémon Go Users Are Adding Fake Beaches to OpenStreetMap

Published on by Jonathan Crowe

Some Pokémon Go players are apparently adding fake beaches to OpenStreetMap in order to improve their chances of catching a new pokémon. The pokémon in question was added to the game last month and only spawns in beach areas. Pokémon Go uses OpenStreetMap as its base map. It’s not hard to see how players can cheat by adding natural=beach nodes where no actual beaches exist, and indeed beaches started turning up in odd places in the game—and in the real-world map as well, because the game uses real-world map data, and that’s what gamers have been messing with. Receipts at the OSM community forum thread. [Atanas Entchev]

Vector Tiles Are Coming to OpenStreetMap

Published on by Jonathan Crowe

On the OpenStreetMap blog, an announcement that vector tiles will be coming to OSM later this year. This is a significant, if belated technical change: other map platforms moved to vector mapping years ago (Google announced the change in 2013). But there are reasons for the delay:

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

Mapping North Korea in OpenStreetMap

Published on by Jonathan Crowe

Mapping North Korea in OpenStreetMap is, by necessity, an exercise in armchair mapping—i.e., drawing maps from aerial imagery and other data sources—because on-the-ground mapping is, to say the least, impractical. French OSM user Koreller has created a North Korea mapping guide for OSM contributors.1 See Koreller’s diary entry about the guide, plus their entry about mapping the North Korean capital, Pyongyang.

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