Improve engagement with data consumers

General talk Tagging general discussion
1

In the recent long discussions on the perceived weaknesses of the highway=path tag, it was mentioned several times that if only data consumers would take into account secondary tags added to paths, these problems would be solved.

One issue mentioned was that sometimes inexperienced hikers are getting into dangerous situations that need rescue operations because on the OSM-based map they were using, it was unclear for them that the path they chose was more dangerous than they could handle. We have the sac_scale key to indicate hiking difficulty, but this key is often not taken into account in general-use map and routing apps: these show all highway=path in the same way.

Another issue mentioned was that bicycle routing apps generally prefer to route cyclists over ways tagged as highway=cycleway, even though some are only meant to be used by MTB bikes and can’t be safely used by an average cyclist on an average road bike. We have the key mtb_scale to indicate the difficulty of cycling on paths, but again this key is often not considered in general-use map and routing apps.

One may argue that by providing the difficulty information, our job is done and our responsibility ends: it is up to data consumers to use the information to provide maps and routing that will make map users aware of the issues a certain way may have and take appropriate action.

However, I think most of us will agree that we can’t just throw this over the wall: we need to interact with data consumers to increase the chance that the data we provide is used in the way we intend. This post is an invitation to discuss ideas on improving our cooperation with data consumers.

Could we improve on our communication with data consumers?

One way we could do that is through the wiki. Now it is mostly aimed at informing fellow mappers about how tags are used and how they should be used, and describing general good mapping practices. Could we add information to the wiki aimed at our data consumers, describing our intention of how the data should be used to make maps and provide routing information? This could be both in the form of general wiki articles aimed at data consumers (on routing, rendering, etc.) and in the form of headings within tag and key wiki articles that are aimed at data consumers.

Another way could be through active participation in the development of apps using OSM data by providing feedback and bug reports. This could be by participation in app Githubs, organised reporting of bugs, and publishing app reviews on a dedicated OSM website and on Google Play. Some mappers may see a business opportunity here by offering themselves as consultants.

Could we encourage data consumers to use our data as intended?

Could we reward apps “correctly” using OSM data? We could award them with our “stamp of approval”, provide certification, and award them with “best app of the year” awards.

Could we force data consumers to use our data as intended?

Are there legal ways to enforce certain use of data, as additional conditions on the license we provide? Could we refuse the right to use our data to consumers that don’t follow our guidelines on intended use?

Your thoughts please!

7 Likes
2

From my limited experience, talking to consumers is more likely to get something worked on. Especially third party consumers.

3

Yes, that’s definitely a missing piece.

Another approach could be encouraging more third-party developers to join forum and wiki discussions, contributing to decisions directly.

Why not feature them on the OSM website? It’s great marketing for apps that follow the guidelines.

Not sure how to motivate OSM contributors in that direction. I’ve personally submitted dozens of such reports but often feel like a lone voice. Meanwhile, countless hours go into forum debates about new tag ideas—issues that could be resolved faster if third-party developers acted on reported bugs.

4

Could we establish some official group of contributors that coordinate between themselves on how to approach data consumers (using this forum as a discussion platform), and allow one of them to speak on behalf of the group when reporting bugs? That person could then also invite data consumers to join the discussion.

1 Like
5

I think you’re barking up the wrong tree if you think the issues here are “engagement” and “communication”.

The problem is that OSM tagging in some areas, like, yes, paths, is genuinely terrible, inconsistent, over-complex and unstable.

The investment required for a general-purpose data consumer to cope with that does not, broadly speaking, have a good RoI. Mapbox are not going to sell many more background maps for people’s websites if they start parsing whatever is tagging flavour of the week. So they won’t. Niche data consumers like me will do so, but tbh the amount of churn in path tagging is too much for even me to keep up with, and I live and breathe this stuff.

It isn’t a data consumer issue. It’s a tagging issue.

10 Likes
6

This kind of information is more than welcome on the wiki. There’s an opportunity not only for mappers to communicate their intentions with prospective software developers but also for software developers to communicate common pitfalls and poor assumptions about their craft.

Traditionally, we’ve dusted our hands after adding a hypothetical rendering to a tagging proposal or the “rendering in OSM Carto” to an infobox, but the irony is that software developers rarely have any reason to follow these prescriptions, and yet there’s so much more to software development that goes unsaid. Rendering, geocoding, routing, and querying all have a certain mystery to the average mapper. A better educated community of mappers could potentially develop better tagging schemes.

More robust documentation is not a panacea. It won’t fix a flawed tagging scheme and may even paper over its flaws. We have many obscure wiki pages from years ago that purport to show how one would write a routing or geocoding algorithm, written by a mapper suffering from Dunning–Kruger syndrome. Worse, we have some tagging schemes that were prematurely optimized for a concept of a router or geocoder that turned out to have no basis in reality. This documentation can mislead developers just as badly as a hallucinating LLM.

Even so, I’d welcome more emphasis on software development in our tagging pages, at least to ground the rest of the content. Some articles spill lots of ink discussing arcane tagging debates while ignoring a strong consensus from the software community. A positive first step would be to simply catalog existing software support on these pages, using taginfo’s project pages as a (very limited) starting point.

4 Likes
7

I sense that the problem with us mappers is that we want to describe the complex reality that we want to map with an ever increasing number of tags of increasing complexity that also develop in meaning over time, without taking into account that that same complexity causes them not to be used by the customers we want to serve. I wonder how we could still allow the complexity that is deemed necessary by most mappers to describe reality, but at the same time reduce the investment that our customers need to make in order to use it.

Taking highway=path as an example, it is a fact that in the real world that we are trying to map, there is a huge variety of paths that are difficult to classify into a small number of clearly defined groups because the border lines between them are not sharp and depend on the person using the path, his skills and the equipment he is using. I think it is not feasible to develop a clear set of classes for paths. Instead, the quality tags such as sac_scale, mtb_scale, smoothness, etc. that we already have allow for a reasonably verifiable description of a multidimensional spectrum of path properties. That then allows data consumers and map users a free choice of classifying paths based on those tag values, depending on the intended users of the maps to be developed (for data consumers), or personal preferences (for the map user). A data consumer for a general audience could decide that paths with sac_scale more difficult than mountain_hiking are too difficult for their users. They could decide not to show them on their map and not route over them, or they could decide to use them but with a warning added. A data consumer making a specialised hiking app could decide to render paths with different sac_scale differently, so their users can decide for themselves what paths they want to hike depending on their preferences and skills. A map maker could also be held liable for causing danger to their users when not using sac_scale. If we describe these considerations on the wiki (and add this link to warn them of their liability) and provide advice on how to classify paths based on their quality tags, wouldn’t that reduce their investment so that they will start using at least some of these tags that we find most important?

8

that would require changing license

and if defining how ta handle various way (tagged highway=path and similar) is complex, then imagine legally defining what distinguishes “evil use” from “good use” or “competent use” from incompetent one!

“do no evil” licenses were tried before and in general they simply do not work

in general we can do it right now, though some past attempts at doing this were horribly confusing, wrong and misleading

(one of the worst offenders is PTv2 proposal where someone made well intentioned mistakes and wasted enormous amount of time of everyone involved on pointless doing something, in misguided attempt to make life of data consumers easier)

1 Like