Welcome! Open Source is a treasure we all benefit from and OSM contributions are a fantastic way to pay the favour forward. It’s great to see your enthusiasm! :)

IMO, the chat issue has slipped through the cracks because the proprietary tools are run by entities other than the OSMF. Nevertheless, it has a greater impact on a regular OSM contributor (as opposed to an OSMF working group member) who wishes to use FOSS than many of the tools listed in the report. So while it may not fit the scope of the report well, I believe that bridging existing communities with a Matrix server is the way forward, and that the OSMF should help make that happen.

I also agree with some of the criticism of the community Index, especially given that it is – through iD – arguably part of the OSM website. Before this discussion, it always recommended proprietary platforms over our own, self-hosted ones, and it still does so by default unless a local community explicitly requests a different prioritization.

in practice it can leave the mappers and data consumers with no way to map something

Wiki voting isn’t the only way for a tagging idea to become established. There’s also the option of establishing a tag through usage in the database and applications.

As such, the wiki process as it stands isn’t designed to always produce a winner. The purpose of wiki voting is just to speed up the process for cases where a good solution is obvious.

In those clear-cut cases, it wouldn’t be worth it to wait for a de facto consensus to emerge, as that might mean a few years of ambiguity and slower progress. But when there is no clear best solution, there is some value in the slower approach of gaining mindshare among mappers and developers until the idea becomes established: It means that the tagging idea will actually have to prove itself to some extent. It may well turn out that none of the initial tagging suggestions was a good one because a proper solution requires, for example, better editors or improvements to the data model first, which cannot be brought about with voting alone.

This is awesome, thanks a lot! I’ll make sure to drop by the issue tracker if I discover any bugs. So far it works like a charm!

I can only speak for myself, but I’d find support for tags useful. In addition to the OSM Wiki and Taginfo, I’d also use the feature for Taghistory and Overpass Turbo, and I’d probably define a few links to frequently-used Taginfo subpages for my own use as well. (Overpass is one-way, sadly – you can get there with an URL containing a key and/or value, but it instantly forwards you to a different URL.)

Would the extension be able to understand that {osm_tag_key} can be used together with {osm_tag_value} as well as by itself? Or would there be a separate parameter for the key-only case vs. the key-of-a-tag case?

This is a great feature, thank you! I expect myself to get a lot of mileage out of the various id parameters as well as osm_user_name. :)

Is there a chance that we’ll see additional bracket parameters in the future? For example, I often find myself switching between different pages for tags (i.e. key and value somewhere in the URL) as well as keys, and this seems like it would fit the concept.

Rob, be assured that members of the board spend thousands of hours on the community’s communication channels, at OSM events, and in direct conversations with other members of the community. This may not be explicitly labelled “outreach”, and we aren’t usually writing blog posts about it because it’s just a normal part of daily life for us. Still, it serves many of the same purposes of keeping an ear to the community’s concerns and informing our next steps on the board.

Allan’s outreach strategy complements our usual methods in that it reaches some people who we otherwise don’t hear from as much (and vice versa, of course). Our 2019 Pre-F2F and Pre-SotM surveys had similar benefits in unlocking input from additional corners of the community.

But please don’t assume that we don’t listen as a matter of course, and that this is more than the tip of the iceberg. If any of the community members who read this have something to share: You don’t have to wait for us to call you! Your views are valuable, so please don’t hesitate to discuss them publicly on one of OSM’s platforms, or to approach the board or one of its members directly if you prefer.

It’s definitely a cool demonstration of what’s possible with Wikidata! I’d like to see more projects make use of the many links between the OSM and Wikidata ecosystems, so in that light, it’s no doubt a great project. :)

When it comes to the reliability of the resulting translations, though, I feel SomeoneElse’s objections are, at least currently, justified. It’s true that there ought to be a semantic equivalence between a tag and the linked Wikidata item, but wiki editors are often tempted to link items that don’t match precisely. To use an example from your post, traffic_calming=chicane is linked to “chicane”, defined as “artificial feature creating extra turns in a road, used in motor racing and on streets to slow traffic for safety”. But as far as I know, the traffic_calming key is not intended for motor racing, which would make this a false equivalence.

There are also cases where the Wikidata definition is a good match, but translated terms can still be misleading. For example, you mention footway=sidewalk and Q177749, where the German label is “Gehweg”. This term is ambiguous: While it often means “sidewalk”, it can also mean “footpath” – which might lead to incorrect use of the tag.

I also tend to find the “artificial buckets” annoying. Not only do they make tags harder to remember and cause discussions about which bucket to put something in almost every time we invent a new tag, they can also lead to misunderstandings about the meanings of a tag. Particularly infamous in this regard is the “natural” key, which has a tendency to make people assume that they are only allowed to tag “natural water” or “natural peaks” with those tags.

In theory, it would be possible to get rid of the problem without an API change by introducing a special key such as “feature”. The values of that key would then be the feature’s type such as “park” or “farmyard”. Replace the arbitrary small buckets with a single big bucket. But it would still be a massive change that is unlikely to ever happen, sadly.

Personally, I try to always add units to avoid any ambiguity. Sure, defaulting to SI units makes sense. But when some keys want meters as the default (e.g. maxheight), others want kilometers (e.g. distance), and again others want centimeters (e.g. the proposed step length), then mistakes will happen. Always adding the unit is easy and fixes that issue.

Personally, I try to always add units to avoid any ambiguity. Sure, defaulting to SI units makes sense. But when some keys want meters as the default (e.g. maxheight), others want kilometers (e.g. distance), and again others want centimeters (e.g. the proposed step length), then mistakes will happen. Always adding the unit is easy and fixes that issue.

@escada: Sure, you will get different results depending on whom you ask. But it’s not automatically true that Germans will prefer orange-red motorways. I’m German, but I’ve never had much exposure to Michelin maps. (I’m probably too young.) So to me, blue seems like a perfect colour for motorways.

That’s not an enviable situation you are in. It’s always annoying when we have to fix mistakes of new contributors instead of spending the time on mapping.

There’s one thing I wonder about, though: If there are only 2 active mappers in that metropolitan area, where does all the data come from? Have there been other contributors in the past that are no longer active? From your post, it sounds as if you are maintaining much more data per user than mappers in my area are.

Popular validation tools such as the JOSM validator or Keepright are grouped by location (i.e. presented on maps), which allows me to look for errors in my local area and check them one by one.

Compared to this, I feel the solution of adding a lot of Taginfo/Overpass links across the wiki isn’t really useful because I would have to open each link individually, just to learn whether there is any instance in my area (with only about 100 instances globally, probably not). These entries in the wiki can only effectively be used for mass edits, which we don’t want.

So I would prefer if you didn’t add your findings as (likely never-ending) tasks to the wiki, but instead contacted the people behind existing quality assurance tools.

Oh je, das sind keine schönen Erfahrungen. Wenn man etwas umbaut, dann sollte man auch darauf achten, dass nichts kaputt geht.

Bei den maxspeeds am Node habe ich allerdings eine Vermutung, was im Kopf des Users vorgegangen ist: Die meisten Fälle, wo maxspeed an Nodes hängt, entstehen nämlich, weil jemand beim Hinzufügen der Tags zu einem Way versehentlich die Nodes mit ausgewählt hatte. Womöglich ist dem User gar nicht eingefallen, dass damit Verkehrszeichen gemeint sein könnten.

Daher habe ich einen Tipp: Schau dir mal den Schlüssel http://wiki.openstreetmap.org/wiki/Key:traffic_sign an. Wenn du z.B. noch traffic_sign=maxspeed an deine Verkehrszeichen-Nodes setzt, dann sind deine Verkehrszeichen hoffentlich idiotensicher. Und du machst es gleichzeitig eventuellen Auswertern leichter.

There’s also the issue of getting the millions of $€£ per year that are required to serve a big customer base. Maybe donations or something would work, but we don’t really know that.

If anyone wants to check, the whitelist is here: osm.wiki/MediaWiki:Captcha-addurl-whitelist

Much better. Thanks!

I also think this style of attribution goes too far. I’m fine with clicking for attribution, but giving special treatment to your own logo in that manner is just not ok.

However, It’s great news that DuckDuckGo uses OSM!

Du hast die 3704346 mittlerweile ja gelöscht, aber ein klarer Fehler war, dass du die runde Wasserfläche mit der Rolle “outer” eingebunden hattest, obwohl es sich nicht um eine äußere Umrandung handelt. Richtig wäre hier “inner”.