Note that problem is not specifically about abandoned=yes (which is fine in some cases, like quarries)

It is also about say proposed=yes ( https://taginfo.openstreetmap.org/tags/proposed=yes#overview ) and many other similar tags

Oh, and it is also danger of being to edit happy and then damaging data more than improving it (or ending with case where others think it happened due to lacking or missing communication). This also happened recently to me and I am still fixing it.

See also https://wiki.openstreetmap.org/wiki/Automated_Edits_code_of_conduct

for first link target was supposed to be https://codeberg.org/matkoniecz/OpenStreetMap_cleanup_scripts/src/branch/master/script_assisted_cleanup/obviously_mistagged_tags_using_trivial_tag_fixes.py

Note that (based on my own experience) it is easy to fall into trap of finding a lot of things to fix then not managing to fix even small part of that.

So I would encourage to balance fixing/finding things to fix.

(BTW, I have obviously_mistagged_tags_using_trivial_tag_fixes.py and obviously_mistagged_tags_using_wrong_keys.py )

SCEE is also from F-droid, maybe only from F-droid

Sometimes it takes multiple seconds to load page of text on modern laptop with 16GB RAM.

Discourse is simply incredibly slow, bloated and poorly optimized like large part of software nowadays.

I am confused by

it would introduce the concession (and all the more so if it is accompanied by a local chapter status) of a monopoly of the use of the OSM trademark on a territory to an economic structure

Why you consider it as giving monopoly on the use of the OSM trademark on any territory? There are no plans at all to revoke other OpenStreetMap trademark agreements in France.

I suspect that automatic translation failed here, but sadly I do not speak French.

maybe something indicating that you map some specific topic?

MapEverything? DeepMap? MapLens? MapTelescope?

It may be a good idea to post about it on https://community.openstreetmap.org/ and/or submit it to Weekly OSM and/or post on dev mailing list.

related:wikipedia - maybe a better name can be invented? I am pretty sure that with such name sooner or later someone will add related:wikipedia=en:Building to every single building or something similar.

Maybe just link wikidata where there is no Wikipedia article?

Propozycja: listuj te OK w osobnej liści na końcu by nie mieć ekranów “1 jest OK” itd.

W https://matkoniecz.github.io/OSM-wikipedia-tag-validator-reports/ to fajnie działa.

Może https://starsep.com/osm-wtp/ by mogło stronę na githubie linkować?

Thanks! I will look at it!

I wonder would it be feasible for you to detect problem of “wikipedia/wikidata linked multiple times and it is not waterway/pipeline/railway/roads/etc[1] feature where linking multiple times may be correct” (or maybe you detect this kind of issue already?)

[1] I have list of such features and Ruby script trying to detect features invalidly linked multiple times.

BTW, I tried editing using Osmose and run into https://github.com/osm-fr/osmose-frontend/issues/437

https://wiki.openstreetmap.org/wiki/OpenStreetMap_Wikidata_Quality_Checker

Project Repository: (tba.)

Can you publish it?

Congratulations!

Below, my proposals :

Thanks for this logos ( https://wiki.openstreetmap.org/wiki/Special:ListFiles/LySioS ) !

But note as they are based on already existing logo which is CC-BY licensed - you must credit its authors (sadly it is a bit tricky, see https://wiki.openstreetmap.org/wiki/File:Public-images-osm_logo.svg and its talk page)

Some people advocated migrating preset definitions to Data items - but as someone developing one of editors I just do not see it as a viable solution.

See how some OSM Wiki articles are contradicting each other or end in confusing weird states as result of compromise. Or have temporarily absurd claims before it gets fixed.

That is survivable in documentation treated with some scepticism. That is not viable for editor presets.

Sorry for silly list formatting above. Also, I am not claiming that data items cannot be useful, just explaining why they were completely pointless for me, and this reasons may be shared by some other people.

I’m genuinely interested in knowing why the Data Items was not used to its full potential.

You probably have seen my comments already but for me there are following reasons:

• data quality is lower than in what is specified as parameters of infoboxes (due to serious UX problems - one major part is tracked as https://phabricator.wikimedia.org/T43686 but see also for example https://wiki.openstreetmap.org/wiki/Talk:Data_items#Order )

As watchlisting interface is atrocious damage will be easily missed. I bet I could find silently redefined/broken data item descriptions that were left without reaction if I would cobble together more complex interface (unusable by others due to reliance on scripting).

• data items do not contain anything so structured. In vast majority of uses you would take image and description, which may be as well as taken from infoboxes. Wikibase is complex and allowing storing structured data (sources, qualifiers and many other) which is not used at all in data items as far as I can see.

• In many cases all this data is useful as giving hints and needs to be looked on manually anyway, at which point any benefits of easier automation are completely disappearing and you are left with only disadvantages

For example I use OSM Wiki heavily while developing StreetComplete. Images from OSM Wiki are sometimes useful, but often different are needed. And cropping them is always necessary.

So OSM Wiki illustration are only the first candidate at most.

I could look at data items instead but what is the benefit here? How I would benefit from automation?

The same for goes for descriptions, due to different context StreetComplete needs a bit different descriptions than OSM Wiki (or data items) are using.

I basically gain nothing by interacting with data items (or even lose due to janky interface and some items randomly displaying images at the bottom because Wikibase cannot even display properties in consistent order)

• wikibase API is complex, annoying and troublesome. In comparison using https://github.com/earwig/mwparserfromhell allowed to get me parsed infobox parameters in time that I used in failed attempt to get “required tags” field out of wikibase API. Going by name mwparserfromhell is dealing with a lot of complexity underneath, but as user of this it was really pleasant.

• data stored for example in https://wiki.openstreetmap.org/wiki/Property:P12 is often really dubious and poorly defined to the point that relying on it is a mistake

that are notable to be on OpenStreetMap

I would rather phrase it that OSM has no notability requirements whatsoever

If you are trying to add it to the map, the you need to edit map at https://www.openstreetmap.org/