So wird StreetComplete für Wartung der Karte taggen

Communities Deutschland (Germany)
1

Hier ist eine Zusammenfassung aller Aufgabentypen in StreetComplete die in bestimmten Intervallen alle Jahre wieder erfragt werden, wie das getaggt wird und andere Bemerkungen dazu:

https://github.com/westnordost/StreetComplete/issues/1998#issuecomment-677825912

Es ist auf English, aber mit Google Translate oder Deepl.com sollte das kein Problem sein. (Nachtrag: Meine Güte ist Google Translate immernoch schlecht selbst bei Englisch nach Deutsch)

Gerne interessehalber reinschnuppern, gerne auch Feedback geben. Vielleicht sind da noch Fehler drin oder ich habe irgendwas wichtiges nicht beachtet. Zwei Aufgabentypen sind noch nicht in der Liste weil ich noch daran arbeite, Überprüfung der Öffnungszeiten und Überprüfung der Art des Fahrradweges.

Das verlinkte Ticket auf GitHub enthält auch sonst alles was man über das neue Feature wissen muss ganz oben in der FAQ und sonstige Diskussion darüber. Vorausgegangen dazu ist ein Thread in der Tagging-Mailingliste sowie kollaboratives Zusammentragen von Erfahrungswerten im Wiki (auch im Ticket verlinkt).

2

Erstmal super, vielen Dank für deine Arbeit!

Das verstehe ich nicht so ganz. Heißt das, dass wenn ein User alle zu recycelnden Materialien angibt und beispielsweise “clothes” nicht darunter ist, dass SC ein bestehendes recycling:clothes=no dann löschen würde? Oder hab ich das falsch verstanden?

Naja gut, ergibt irgendwie dann doch auch wieder Sinn.

3

Bezüglich dem “check_date:shelter” bei bus_stops:

Gibt es wirklich Bushaltestellen, an denen bestehende shelter ersatzlos wieder abgebaut werden? Also meint ihr, dass muss für shelter=yes wirklich auch gefragt werden?

4

Und dann noch ein ganz anderes Thema: Jetzt wo check_date integriert wird, gibt es irgendwie die Möglichkeit, so eine Art check_date:existance oder so etwas für öffentliche Telefone zu integrieren? Na ja, ist jetzt wahrscheinlich weit hergeholt, da so etwas dann doch was anderes wäre als die Wartung wirklich einzelner, bestehender Tags.

5

Zu Recycling:

Kurz: ja.

Mehr Info: Also, der Nutzer bekommt generell in der App die Anweisung, alles auszuwählen was man dort recyclen kann und zusätzlich den Hinweis “Wenn noch Anderes entsorgt werden kann als man hier angeben kann, bitte hinterlasse stattdessen eine Notiz.”.
Alles was er dort also nicht ausgewählt hat, ist implizit “no”, aber das wird ja in der Regel nicht getaggt es sei denn jemand möchte explizit darauf hinweisen dass etwas “no” ist.

Also wenn da schon sowas steht wie recycling:li-ion_batteries=yes, dann soll garnicht erneut gefragt werden, denn Li-Ion-Batterien kann man in der App nicht auswählen. Der Nutzer müsste also alle 2 Jahre eine Notiz hinterlassen in der er das beschreibt und hoffen dass das jemand anders dann einträgt (bzw. nicht einträgt, bleibt ja alles gleich), das wäre doof. Daher wird bei der App unbekannten recycling:=yes* Werten garnicht erneut gefragt.

Aber unbekannte recycling:=no* werden einfach komplett ignoriert und auch nicht gelöscht oder geändert denn hier wollte ein Mapper wohl nur explizit darauf hinweisen dass man etwas dort nicht entsorgen kann, z.B. recycling:window_glass=no.

Zu shelter

Ist mir noch nicht untergekommen. Aber generell wenn z.b. ein Straßenabschnitt neu gemacht wird, das Verkehrskonzept also umgestellt wird um mehr Platz für Fahrradfahrer, oder Fußgänger zu schaffen, oder wasweißich, dann werden in der Regel auch die Bushaltestellen direkt ab- und wieder neu aufgebaut. Hier ist es zumindest theoretisch möglich, dass ein solches “Feature” wieder entfernt wird, genauso wie es unwahrscheinlich aber auch möglich ist, dass die neue Bushaltestelle keine (oder falsche!) taktile Pflasterung hat, dass eine renovierte Treppe plötzlich kein Geländer mehr hat obwohl es eines hatte und so weiter und so fort.

Wenn man überhaupt nicht mehr erneut überprüft wenn bestimmte Upgrades (Rollstuhlgerechtigkeit, Blindengerechtigkeit, Dach, Geländer usw) erreicht wurden, dann läuft man Gefahr dass wenn diese dann irgendwann doch nicht mehr existieren (oder fälschlicherweise so getaggt wurden), es niemand mehr mitbekommt.

Zumindest bei z.b. taktiler Pflasterung ist es ja so, dass Nutzer es dann doppelt so selten überprüfen sollen ob es noch da ist.
Könnte man auch bei Dächern von Bushaltestellen so machen. Was meint ihr?

6

check_date:existance

Interessant, das wurde gerade erwähnt in diesem Bugtracker hier: https://github.com/pietervdvn/MapComplete/issues/68

Jo, wäre schon sinnvoll. Dann könnte man überprüfen ob ein Telefon noch da ist, ein Postkasten, eine Bank, eine Picknicktisch, ein Mülleimer, usw usf, allerdings ist das zurzeit in StreetComplete nicht möglich, da StreetComplete bisher nicht in der Lage ist, Elemente zu löschen.

7

Ja das wäre toll :sunglasses: Auch für shop= usw. Manchmal gibt es viele Jahre manche Dinge nicht mehr und es fällt einem einfach nicht auf :roll_eyes:

Hab da auch mal was angefangen aber nie weitergemacht… Anhand vom timestamp() per Overpass zu suchen… so in der Art:

node[~"shop|tourism|healthcare|office|opening_hours"~"."]
  (if: timestamp() < "2014-01-01T00:00:00Z" )({{bbox}});

und dann einen check_date:2020-… dran wenn es es noch gibt…

Manche Dinge sollte man vielleicht öffers schauen, andere alle 10 Jahre ok.

Gruß Miche

8

Supa, danke schon mal für die Antworten, dann weiß ich Bescheid und kann die Argumentation bezüglich shelter z. B. auch nachvollziehen, ist ok.

9

muss ja von sc nicht gelöscht werden. Eine note setzen, dass das Objekt nach Überprüfung vor Ort am… nicht mehr existiert/entfernt wurde oder so ähnlich würde reichen. Wenn es ein anderer dann mit nem Editor löscht wäre das aus meiner Sicht i. O.

10

ja seh ich auch so… ist eigentlich jetzt schon so praxis, wenn eine Quest nicht gelösst werden kann weil es nix mehr exitstiert.

Edit:
So wie hier: https://www.openstreetmap.org/note/2265420

11

Recyclingcontainer

Eine Frage habe ich noch:

Was macht SC, wenn wir Situationen haben wie hier: https://www.openstreetmap.org/node/7803904257

Recyclingcontainer-Standorte können in einzelne Nodes aufgetrennt sein. Manchmal unterscheidet sich der operator, manchmal möchten Mapper die Container einzeln sehen und wenn Altglascontainer dabei sind, dann ist eine Trennung auch oft notwendig, da die Einwurfzeiten nur für die Glascontainer gelten.

Aber wenn ein User jetzt den Altkleidercontainer angezeigt bekommt, und dort nach den Sachen gefragt wird, kann es dann nicht sein, dass er denkt “da fehlt doch die Angabe des Altglases”? Der Container ist ja in OSM direkt daneben, aber die Angabe aller zu recycelnden Materialien kann halt nur durch das Beschauen mehrerer Nodes gesehen werden…

12

Tolles Projekt, dieses StreetComplete! Hatte ich nicht auf dem Schirm, kommt vor meiner nächsten Reise aufs Handy.

Briefkästen checken finde ich wichtig, auch weil es in Wirklichkeit immer weniger davon gibt, aber auf OSM bleiben manche zombiemäßig jahrelang stehen… Dafür fände ich etwas wie check_date:existence sehr hilfreich, damit man weiß, welche schon überprüft wurden. Ich mache das in meiner Umgebung händisch: verschwundene Briefkästen löschen und den anderen ein survey_date geben (kommt aufs selbe raus wie check_date). Meine Overpass-Query zur Survey-Planung, falls das wem hilft: http://overpass-turbo.eu/s/XgM
Briefkästen, die seit 2019 verändert wurden, werden grün angezeigt. Die anderen rot (die schaue ich mir an). Ist für mich Beifang. Wenn ich sowieso irgendwo hingehe, baue ich noch einen Schlenker zum Briefkasten ein.

Bei Bushaltestellen schaue ich auch systematisch nach shelter, bench und wheelchair. Veränderungen sind meistens von no nach yes, aber das Gegenteil kommt durchaus vor. Macht also Sinn, das in StreetComplete abzufragen.

13

Oha, nene so komplex ist es nicht das in StreetComplete einzubauen dass es auch Elemente löschen kann. Aber ist jetzt erstmal nicht für dieses Feature geplant, kommt aber noch! Für welche Objekte genau würde denn ein “ist x noch da” Sinn machen? Gerne kann hier schonmal eine Liste erstellt werden, dann wird gleich zu Anfang wenn es implementiert schon viel abgedeckt.

Danke dass du mich darauf aufmerksam gemacht hast. Das ist ein Problem. SC zeigt auf der Karte nicht an dass genau daneben noch ein Container gemappt ist, und schon garnicht was für Recycling-Typen dort akzeptiert werden. Eigentlich sehe ich hier nur die Lösung, dass Container-Nodes die einen weiteren Container in unmittelbarer Nähe, sagen wir in einem Radius von 10m haben, von der Re-Survey ausgenommen werden.

14

Leider muss es dann wohl so sein, ja. Ich hätte es auch manchmal gern lieber, wenn alle Container-Sachen auf einem Node wären. Aber wie schon gesagt, geht das leider manchmal wegen verschiedenen Betreibern oder Einwurfzeiten nicht.

15

10m ist wohl etwas wenig (weil die GPS-Position des Nutzers ja nicht immer absolut genau ist), habe mal 20m genommen. Die Query ist jetzt


[bbox:{{bbox}}];
node[amenity = recycling][recycling_type = container] -> .all;

node.all[~"^recycling:.*$" ~ "yes"] -> .with_recycling;
(.all; - .with_recycling;) -> .without_recycling;

node.with_recycling[~"^(recycling:glass_bottles|recycling:paper|recycling:plastic|recycling:plastic_packaging|recycling:plastic_bottles|recycling:cans|recycling:scrap_metal|recycling:clothes|recycling:shoes|recycling:small_electrical_appliances|recycling:batteries|recycling:green_waste|recycling:cooking_oil|recycling:engine_oil)$" ~ "yes" ] -> .with_known_recycling;
(.with_recycling; - .with_known_recycling;) -> .with_unknown_recycling;

node.all(if: date(timestamp()) < date('2018-08-21') || date(t['recycling:check_date']) < date('2018-08-21') || date(t['check_date:recycling']) < date('2018-08-21') || date(t['recycling:lastcheck']) < date('2018-08-21') || date(t['lastcheck:recycling']) < date('2018-08-21') || date(t['recycling:last_checked']) < date('2018-08-21') || date(t['last_checked:recycling']) < date('2018-08-21')) -> .old;

(.without_recycling; (.old; - .with_unknown_recycling;);) -> .recyclings;

foreach .recyclings (
    node[amenity = recycling][recycling_type = container](around: 20);
    node._(if:count(nodes) == 1);
    out meta geom;
);
16

Ja, ich denke das ist so ok. Es gibt in OSM so viele verschiedene Konstellationen zu berücksichtigen (zumindest theoretisch), dass manche kleineren Situationen dann wohl außen vor gelassen werden müssen.

Aber es wurde ein ganz guter Kompromiss gefunden, wie ich finde.

17

Ich fange dann einfach schon mal an. Eine bereitere Diskussion wird es wahrscheinlich noch geben, kurz bevor es implementiert werden würde.

  • Generell ändern sich einige shops schnell. Vor allem so etwas wie variety_store, clothes, etc. etc. Bei shops und Restaurants geht es ja allerdings nicht nur um “ist das noch da?”, sondern oft ändern sich einfach der Name, der Betreiber und manchmal der “type” des shops.

  • Folgende amenities sind aus meiner Sicht aktuell “vom Aussterben bedroht”:

- amenity=post_box (auch Briefkästen verschwinden nach und nach)
- amenity=telephone (akut “bedroht”)
- amenity=clock
- amenity=vending_machine, ich würde das aber nicht pauschalisieren. Vor allem vending=cigarettes, vending=chewing_gums, vending=newspapers, vending=sweets, vending=stamps, vending=condoms, vending=syringes, vending=toys sind zum Beispiel “möglichweise abbauverdächtig”. Wenn es geht, sollte jedoch berücksichtigt werden, dass vending=* mehrere Werte haben kann, und wenn einer davon zum Beispiel “chewing_gums” ist, könnte es geprüft werden. Kaugummiautomaten verkaufen ja manchmal auch noch Kleinspielzeug, deswegen kommen z. B. “vending=chewing_gums;toys” vor.

Obwohl, wenn ich mir das so anschaue, dann sind doch wieder quasi fast alle vending=*s betroffen. Nur vending=public_transport_tickets oder vending=parking_tickets verschwinden eigentlich nicht so schnell von der Bildfläche.

Eventuell auch noch einige seltene** craft=***-Werte, wenn es sich um “aussterbende Handwerke” handelt. Die dürften dann in OSM aber ohnehin selten vorkommen.

18

Hm, selbst die lohnt es sich (zumindest international ) zu überprüfen.

Hier in Schweden gibt’s überall SMS / APP oder Onlinelösungen, weswegen die Dinger auch sehr schnell verschwinden. Es gibt mittlerweile sogar Knotenbahnhöfe wo Du keinerlei Möglichkeit mehr hast, Bahntickets zu kaufen.

Das selbe gilt übrigens auch für Parkscheinautomaten, auch die verschwinden immer schneller.

19

Wer mag kann gerne die Alpha der neuen StreetComplete-Version die all dies beinhaltet testen. Einfach die hier verlinkte APK über die aktuelle Version von Google Play installieren.

https://github.com/westnordost/StreetComplete/releases/tag/v23.0-alpha1

(Falls die App von F-Droid heruntergeladen wurde muss sie vorher erst deinstalliert werden)

20

Zu dem oben genannten fallen mir noch folgende ein (seltener überprüfen):

  • amenity=bicycle_parking
  • amenity=motorcycle_parking
  • Tischtennisplatten
  • Ampeln und Fußgängerüberwege
  • Litfasssäule / Reklame
  • Bankautomaten
  • wayside cross (?)
  • Informationstafeln
  • Parkbank
  • Picknicktisch
  • Mülleimer
  • Trampfelpfade im Wald mit sehr schlechter Sichtbarkeit??