[Polls] Standard for documenting editor/router/renderer support status on tag wiki pages?

General talk Tagging general discussion
, , ,
1

There’s no established convention for how (or whether) a tag’s wiki page documents editor/router/renderer support. Some pages have detailed status, most have none, and where it exists the format varies wildly. Before writing anything prescriptive, want to gauge whether this is worth standardizing, and roughly what it should look like.

Is a standard worth having?

  • Yes, a shared convention would help
  • No, leave it to individual page editors
  • No, this belongs in taginfo instead
  • Not sure / no strong opinion
  • Yes, but only for new or contested tags
0 voters

If yes, where should it live on the page?

  • Its own top-level section (e.g. == Software support ==)
  • A subsection under == External links ==
  • Doesn’t matter
0 voters

If yes, how should status be grouped?

  • Two buckets: Open vs. Completed
  • Split further by tool type (editor / router / renderer)
  • A table with one row per tool, explaining how it’s used (e.g. “GraphHopper: bicycle profile speed penalty”)
  • Link to taginfo’s Projects list instead of maintaining this manually
  • Taginfo as source of truth: structured data feeds an auto-generated wiki template, editors annotate below
  • No strong preference
0 voters

Missing an option? Just comment below, happy to add it.

Voting alone won’t add you to this topic’s notifications: use the bell icon at the bottom of this topic (or stay on the thread) if you want to be notified when results or follow-ups are posted.

Some context, for anyone who wants it before voting:

Example of what one page currently does: Tag:surface=laterite § Software support

This isn’t a new problem. Back in 2009-2010 there was a cross-renderer/editor support comparison (Mapnik, Osmarender, Potlatch, JOSM, Kosmos), building on an earlier version, but it stayed a personal user-subpage and never became a wiki-wide convention. More recently, a 2022-2023 wiki discussion explored moving software capability data into Wikibase instead of hand-maintained tables, after a bot that used to keep such tables in sync (TTTBot) stopped running and nobody picked it back up. That thread was closed as “nothing actionable” without a resolution.

Taginfo already has something for this, its Projects feature lets software declare which tags it uses. Unfortunately coverage is limited: it’s opt-in, so a project only shows up if someone submitted a project.json for it, and even then it just says “this project references this tag somewhere,” not whether support for a specific value is open, in progress, or shipped.

Happy to draft an actual guideline page once there’s a rough consensus here, this is just to check direction before doing that.

2

I think it depends. If tag is new or with divided/controversial situation (see highway=busway or surface=laterite) it makes sense to list it.

But once tag is widely accepted and supported, it should not be there. For example listing every data consumers supporting natural=tree would be absurd. And taginfo tag page is linked, so linking also sections of it is pointless.

4 Likes
3

surface=laterite isn’t “divided/controversial.” The proposal passed 29-0-0, zero no votes, zero abstains. Every editor and router that’s touched it since merged support within about a month, no debate.

The only friction is the OpenStreetMap Carto PR, and even imagico says it’s not about validity: “OSM-Carto has no position whether the idea to tag roads with surface=laterite is a good idea or not”, just a rendering adoption-threshold disagreement, applied the same way to everything (surface=rock, 25k uses, isn’t classified there either). He’s also on record that OSM Carto doesn’t speak for “actual OSM.”

You raised a real concern on id-tagging-schema#2332 in June, I answered it in full, twice. No reply since, on the issue or on the PR implementing it, ready for merge over a week now. If you thought the tag was a bad idea, the vote was the place to say so, not this.

4

that is why I also put there “If tag is new” part, if tag is quite new then it is both of interest for community to see how adoption goes in software and it may take a while for issues/PRs to be processed

(for example one in iD tagging schema for now has not got review IIRC, though I hope to get to it soon - just that recently I and others were processing some other PRs)

and for highway=busway main controversy is Carto refusing to render it even like highway=service, not tag itself IIRC

3 Likes
5

I think yes it would he helpful AND it should be left to the individual page editors if they use it, dont use it or use a different style.

A template or something could save time or ensure a more complete list of softwares being documented.

My main concern is, that information on the wiki will get outdated. So at least there should be a “check date”.

1 Like
6

I think this is an attempt to exert pressure on tool and map style writers and I reject this attempt. Our method of coming up with new tags and voting on them is flawed; it is too easy for niche interests to push trough some silly tag that 99.9% of OSMers have zero interest in. It is good that map style writers and editor writers do not blindly follow every vote result, but implement their own checks and balances - what target audience is my software/map style/… for, and do I really want to support this new tag. Editor and map style writers should not be shamed into compliance (“TWENTY NINE PEOPLE have agreed that this is a good tag so you must now add it to your editor used by thousands!!!”).

6 Likes
7

Nobody said that, here or anywhere in this thread. It’s a status list, shipped vs. open, same as the wiki page already uses, not a compliance mechanism, and “you must now add it” was never the ask.

Agreed, and it’s not in dispute: the proposal process page already says a vote “does not compel a change in tools.” OSM Carto’s PR sitting open as long as imagico wants is exactly what that discretion looks like on a status list, not a contradiction of it.

Not a niche clique: the proposal draft included direct outreach to 100 active mappers across laterite-region countries, 44 of whom responded, and the nine tools that added it since (StreetComplete, OSRM, GraphHopper, OsmAnd, Valhalla, CoMaps, OpenMapTiles, Tracestrack Topo, Vespucci) did it within weeks, unprompted, because it was useful to their users. “Silly” dismisses that work, and coming from someone who’s been part of this project this long, that dismissal lands harder than you probably intend.

1 Like
8

The poll options don’t fully capture my views, which are:

Having both edited a fair amount of wiki pages and successfully created a couple of taginfo project files each for both personal and professional projects, I think it’s best/ideal that taginfo be the main source of truth in the form of structured data and have that feed a wiki template.

Otherwise, the wiki articles will drift out of sync - often by years - and a lot of prescriptive/opinionated[1] information (ex: “XYZ editor/router/renderer implements this incorrectly” - often meaning, “not how I want them to”) is introduced.

Individual page editors can always annotate (which is a good thing!) the structurally provided information below the template that inserts it.

  1. which, note, I am not inherently opposed to the wiki containing ↩︎

5 Likes
9

That’s not an accurate summary. Rather than just adding surface=laterite as a new unpaved surface, more than one contributor asked for the values rendered to be updated based on current usage (open issue here). But somebody does need to take this on and update the PR.

10

Added as an option on poll3, thanks. It’s a meaningfully different shape than “link to taginfo instead”: data lives in taginfo, a template renders it on the page, and editors annotate underneath rather than hand-maintaining the whole table. That also answers Nielkrokodil’s “check date” worry upthread, since the rendered section would track taginfo’s current state instead of whatever was typed in by hand years ago.

One question: would this need taginfo’s Projects format to grow a per-value status field (open/in progress/shipped), or would it stay at the current “this project references this tag somewhere” granularity you mentioned?

1 Like
11

I like how the TagInfo-powered approach would avoid stale data. I guess there’s a fundamental downside as well though: it wouldn’t be able to express any nuance about what “support” means?

E.g. in the case of a new surface value, does lumping it into a generic “unpaved” category count as meaningful support? It’s better than nothing, but the whole point of introducing a more specific value is to ultimately get more specific handling for it right?

(…not sure what the best answer is, just musing on the problem!)

1 Like
12

That discussion wasn’t really about tracking which data consumers support which tags. It was higher-level, such as the genre or latest release date of an application. The outcome of the discussion was vastly improved coverage of OSM-related software on Wikidata, benefiting the wider world beyond our community. Bots go around updating the Wikidata items automatically, addressing the original concern. The only drawback is that our wiki isn’t currently set up to pull data directly from Wikidata, only from data items on the same server.

In principle, anyone can write a project file for a project and submit it to taginfo’s maintainer for consideration. It can be hosted anywhere, not necessarily in the same repository as the project’s source code. However, you’d be committing to keeping it up to date as the project changes. Most people aren’t willing to do that unless they themselves are a maintainer.

Having written most of the wiki’s “Software support” sections over the years, I understand the motivation behind this proposal but somewhat disagree with it. I never intended these sections to serve as a kanban board, advocating for all software to move from Unfinished to Finished, as the surface=laterite section implies.

In the sections I’ve written, the message varies from page to page, but it’s generally the same as taginfo’s project tab: to establish that a tag is already being consumed somehow, to give mappers more confidence in the tag or caution against redefining it. It can be a useful opportunity to clarify how the tag is interpreted, since maintainers don’t often explain that well in their project files. In a few cases, the section tracks a friendly rivalry between two competing tags.

The other commenters are correct that this is a maintenance burden. I would prefer to introduce the section more strategically when there’s something noteworthy to explain.

2 Likes
13

I was thinking along similar lines for keys such as building. In a sense most values of this key are supported by lots of renderers, as a more specific value than yes will generally be shown as a building rather than empty space. In another sense most values are unsupported by most renderers, as they render exactly like building=yes. What would a “standardised support status” look like for each building tag?

Mote generally, I would be concerned if a standardised approach imposed expectations on people who are not especially interested in documenting this kind of thing. If I simply want to document an “in use” tag, would there be an implicit expectation that I investigate which data users support it? Similarly I wouldn’t want software maintainers to be obliged to maintain a parallel issue tracker. Maybe that wouldn’t happen in practice, but I’d need more detail on what standardisation means to judge.

1 Like
14

I would say that in such case building= key is supported (and taginfo project report allows listing this)

definitely not, there is no obligation to create full page listing everything in one go

creating page listing something more useful than “is an OSM tag” is enough

1 Like
15

Added that as a poll1 option: “Yes, but only for new or contested tags.” Current lean is still toward “no, taginfo’s job”, so if this doesn’t pick up enough votes it just won’t be part of what gets documented.

Before that plays out though, worth pinning down what “new” and “controversial” actually mean in practice, since the definition decides which tags this would ever apply to.

How long counts as “new”?

And does a single renderer choosing not to draw something make a tag “controversial”, or does that require actual disagreement about the tag itself (see post #3 on what OSM-Carto’s PR is and isn’t about)?

16

Fair, and useful to hear from whoever’s actually written most of these. Good to know on Wikibase too, sounds like the 2022-23 concern got solved differently than I read it.

Checked taginfo’s actual project.json schema since it’s central to where poll3 is heading: each tag entry only has key, value, object_types, description, doc_url, icon_url, no status field at all.

So a project can say it references a tag, or say nothing, there’s no way to express open/in-progress/rejected, and that’s before you get to tools with no project.json at all.

Which means the taginfo-template idea can’t carry the “not a checklist” framing on its own, whatever nuance matters would have to live in the free-text description per project or in the hand-written annotation layer underneath, same place your point about not turning this into a compliance list would need to go anyway. Does that match how you’d expect it to work, or is there a taginfo-side change you’d want first?

17

Fundamentally, OSM operates on a “pull” model, not a “push” model. We collect the data; data consumers decide whether and how to use it. There is value in tracking who uses the data and how. We can coordinate with developers when we go oops and need to change something major. Some of us also prefer to prioritize our individual mapping efforts based on what will show up and benefit end users. When a “Software support” section links to feature requests in various issue trackers, that is an invitation for mappers to study the discussion in that software project, provide constructive feedback as needed, and follow the progress on their own. It is not an attempt at peer pressure.

If we put together a colorful dashboard listing statuses like Completed, In Progress, or Rejected, the atmosphere will change. Mappers and data consumers will perceive it as a “vote” on the tag’s legitimacy, or conversely a push for “conformance” to a standard. At times, an adversarial process has turned out to be necessary. I vividly recall the moment that router and editor developers collectively torpedoed the flawed transit=* tagging scheme. I hope this kind of event remains an exception rather than becoming the norm. A collaborative process is more in line with OSM’s modus operandi.

4 Likes
18

Most support requests actually come from mappers and end-users, not from data consumers independently deciding to add something, and that’s exactly why a grid tracking what is or not supported is still useful, it’s for the people filing and following those requests, not a legitimacy vote.

Agreed it shouldn’t live on the wiki, matches where the consensus here is heading, but if not taginfo either, since its schema has no status field per post #16, then where should it live? An independent project?

19

If you’re mostly interested in tracking projects that are on GitHub, as opposed to other code forges or proprietary products, then you could maintain your own GitHub project that automatically tracks the status of each issue. This would be either a kanban style or spreadsheet style dashboard, not a Git repository. For external projects, you can add notes but would have to track them manually. Unfortunately it doesn’t work like a wiki: you’d only be able to manually give other users the right to help maintain the project.

A project of that sort can also track feature development across the ecosystem, similar to what we did for area routing in an ad hoc manner.

1 Like
20

On your suggestion, I’ve already been experimenting with a routing-support tracker for surface, smoothness, and tracktype together, nothing official yet. Also opened taginfo-projects#279 asking about an optional status field on project.json. Thanks for walking through the tradeoffs, this settled the direction question I came in with.