Was ich gerade noch gesehen habe: Osmose zeigt eine Warnung an für surface=anti-slip auf dem kleinen Wegstück, das damit getaggt ist („Bad tag value|Concerns tag: 'surface=anti-slip'“) ... Weil es undokumentiert ist? Oder wegen des Bindestrichs (mit Underscore wäre wohl besser, aber „anti_slip“ ist noch seltener – nur 1x verwendet)?

Nur zur Info ... das meinte ich aber damit, dass ich undokumentierte (oder neu erfundende) Werte nur ungern benutze.

Denn eigentlich müsste man es im Wiki dokumentieren (bzw. erst im Forum diskutieren?) und dann noch ein Issue für Osmose oder andere Validatoren anlegen etc. ...

Hallo Lukas! Ich hab deine Nachricht heute erst gesehen … Ja, da könntest du recht haben – oder es ist ein schwieriger (Grenz-)Fall. Ich glaube nicht, dass es ein Versehen war, ich erinnere mich aber nicht mehr ganz genau. Die Fotos zeigen es wohl richtig (ich hab auch eins von 2021, sieht genauso aus), aber man kann daraus nicht klar ableiten, was es ist. Typisches (blankes) metal_grid ist es wohl nicht von der „obersten Oberfläche“ her gesehen. concrete oder asphalt stimmt aber ziemlich sicher auch nicht. Es könnte gut sein, dass es Metall ist (bzw. wirklich eine Art metal_grid!) mit einer Anti-Rutschbeschichtung, die wie Beton aussieht auf den Fotos. Es kann sein, dass ich 2023 metal_grid gesetzt hatte, weil der Weg daraus besteht (ob nun mit oder ohne dünne Beschichtung) und mir das als der am wenigsten falsche Wert erschien, also der am ehesten passende (ohne was Neues zu erfinden – was ich immer zu vermeiden versuche). Und weil concrete definitiv nicht gestimmt hat ... Meist bin ich da schon recht gründlich und schau es mir vor Ort an.

Was ich jetzt noch gesehen habe: nw520 hat 2024 bei einem Teilstück zur Treppe den (undokumentierten) Wert surface=anti-slip (mit surface:note=Metall mit Anti-Rutschbeklebung) gesetzt (weltweit nur 45x benutzt). Siehe way/399937342. Aber den Hauptweg nicht geändert – was auch seltsam (und v.a. inkonsistent!) ist. Es ist sicherlich die gleiche Oberfläche. Da müsste man wohl nochmal hin ... Vielleicht kann man auch material=metal (oder metal_grid) und surface=anti-slip setzen? Oder surface=metal_grid + anti_slip=yes? ;-)

Vielleicht hast du ja eine Idee ... Bzw. kannst mir sagen, wie du es machen würdest.

Viele Grüße und danke für den Hinweis

Ja, kein Problem. Ich komme da öfters vorbei, vielleicht sogar heute noch. An den fraglichen Stellen stimmt es wahrscheinlich auch, nehme ich mal an. Es sind auch neue Häuser fertig gebaut oder noch in Bau, von denen nur wenige bisher sichtbare Hausnummern haben (im 3. Bauabschnitt). Ich versuch es im Auge zu behalten. VG!

Hall Teddy73!

Im Neubaugebiet Franzenbrunnen hattest du 2021 mal Hausnummern eingetragen mit der note "Neubau, Hausnr geraten".

Das war nicht immer so ganz glücklich geraten ... ;-)

Z.B. die obere Häuserreihe in der Echternacher Straße ... hier etwa ist es HN 28 statt der geratenen HN 16: way/974090922. Falsch war es ab der jetzigen HN 10. Und 12 und 14 scheint es nicht zu geben, hab ich jedenfalls nicht gesehen.

Ich war gestern dort + war erst mal sehr verwirrt wegen den eingetragenen Hausnummern und denen vor Ort (weil ich auch die note nicht gleich gesehen hab ...). Und mir ist es eigentlich auch nur durch Zufall überhaupt aufgefallen. Hat dann etwas gedauert, bis ich durchgeblickt hab, was zu ändern war und was die richtigen Nummern sind (das falsche Raten lag dort vielleicht an der 2. zurückgesetzten Häuserreihe, die halt mit nummeriert sind – vielleicht gab es die 2021 noch nicht?).

D.h.: vielleicht nächstes Mal besser doch nicht raten. Denn die waren jetzt 4 1/2 Jahre lang falsch ... Es fällt eben kaum auf und man kommt nicht ohne weiteres auf die Idee, dass solche Hausnummern falsch sein könnten. Ich denke, es ist besser, gar keine HN anzugeben, wenn es nicht klar ist. (Wenn neue Häuser keine HN haben, checkt es sicher eher mal jemand bzw. ein fixme, z.B. „Hausnummer noch zu ergänzen sobald bekannt“ könnte sinnvoll sein.)

Wollte es bloß mitteilen ...

Da sind jetzt noch ein paar Häuser mit dieser Note (Louis-Pergaud-Straße 13 bis 25 und Anita-Augspurg-Straße 8, 10, 11, 12) – das hab ich erst zuhause gesehen. Sollte man wohl auch nochmal checken zur Sicherheit und die note dann entfernen.

Viele Grüße und happy Mapping!

Hello!

A small note regarding your changes: you should always add traffic_signals:direction=forward|backward to new traffic_signal nodes on a way (if not on a crossing node of ways) ...

And the new highway=crossing node still had traffic_signals:direction=both. This should be removed, if you change the mapping of pedestrian crossings like this.

I fixed it now.

Best regards!

Hallo! Kleine Info: du hast in der Sulzbachstraße diesen Knoten gemappt mit shop=vacant: node/13534151190. Da gibt es aber schon länger einen Knoten mit planned:amenity=fast_food etc.: node/740865177. (Der hat auch die ganze History seit 2010 mit Café Schubert usw. D.h. ich lösche den jetzt wieder. Vielleicht zeigt StreetComplete Knoten mit planned:amenity ja nicht an, keine Ahnung ... ich empfehle da, einen anderen Editor zu benutzen (oder parallel 2). Viele Grüße!

Hallo!

Kleine Info: du hast da u.a. einen Zigarettenautomaten in der Bahnhofstraße entfernt (zum Glück nur die Tags, nicht den Knoten), aber der ist und war sicherlich nie weg (voller Aufkleber etc.). node/6059224148/history/10. Ich füg ihn wieder hinzu ... Aber bitte sorgfältig sein bei sowas ... Grüße!

Hallo! Du hast die Öffnungszeiten beim Deutschen Kinderschutzbund Ortsverband Saarbrücken (Am Schloßberg) geändert, aber leider falsch. Nur Mo. und Do. nachmittags ist geöffnet, nicht Mo-Th ... (laut Schild).

Ich korrigieren es nochmal ...

Grüße!

Noch eine bzw. 2 Anmerkungen zu diesem oneway-Thema (ich weiß nicht, ob das in der Forumsdiskussion auch jemand angemerkt hat):

Für mich ist Konsequenz und Konsistenz in der Systematik immer sehr wichtig. Es hilft, sich Dinge zu merken. Wenn du sagst, bei einem Fuß-/Radweg sollte der traffic mode explizit angegeben werden per „oneway:bicycle“, dann ist der einzige Grund ja, dass du klar machen willst, dass es nicht für Fußgänger gilt (nehme ich mal stark an). Das Mofa-Problem jetzt mal gerade außer Acht lassend, könnte dann jemand anderes mit gleicher Begründung sagen, dass es bei normalen Straßen, z.B. highway=residential, auch nicht reicht, oneway=* anzugeben, weil ansonsten auch Fußgänger gemeint sein könnten. Es müsste also immer oneway:vehicle=* heißen. Das wäre dann konsequent und konsistent. Aber versuch das mal durchzusetzen ....viel Spaß ...

Der 2. Gedanke folgt daraus: die derzeitige Definition ist eigentlich sehr klug und durchdacht. Denn in bestimmt 99,9% der Fälle gilt oneway=*, auf welchem Weg auch immer, nicht für Fußgänger.

Das einzige, was also wirklich etwas fehlt, ist eine klare Einigung wie das dann zu taggen ist. Dazu habe ich auch eine Diskussion vage in Erinnerung, wo wie gesagt die Lösung per oneway:foot=* die vernünftigste zu sein scheint. So habe ich es mir jedenfalls eingeprägt. Es wurde glaube ich auch diskutiert, dafür neue Tags zu erfinden und anderes (z.B. access-Tags mit :forward/:backward, was aber komplizierter ist und fehleranfälliger usw.).

Also ich finde es eigentlich sehr einfach, dass man sich nur 1x einprägen muss, dass oneway=* nur für Fahrzeuge gilt. Für auswertende Software sollte es auch klar sein. Und in Editoren könnte das auch leicht klar gestellt werden für alle, die nicht ins Wiki schauen (plus Warnungen usw.).

Ich weiß, es gibt dann noch den Fall von highway=steps. Weiß auch gerade nicht, ob das diskutiert wurde. Der Fall mit oneway bei einer Treppe scheint aber so extrem selten zu sein (müsste man mal mit OverpassTurbo checken), dass es nicht mal auf der Wikiseite erwähnt ist (und bei Rolltreppen kann es per conveying=* angegeben werden). Ich hatte den Fall glaube ich noch nie, aber ich würde da dann aus Konsistenzgründen auch oneway:foot=* angeben statt oneway=*, sonst gilt es eigentlich für Fußgänger nicht (foot=yes ist auch bei access statt access=yes stark empfohlen, da gibt es dann auch eine Übereinstimmung, wenn auch 2 versch. Themen).

Vielleicht hast du ja auch noch (andere) Gedanken dazu ...

Grüße!

Hallo! Ich kenne die Forumsdiskussionen auch, und finde sie sehr ermüdend mittlerweile. Dass kein Konsens besteht ist eigentlich bei fast allem der Normalfall.

Ausschlaggebend ist für mich daher eigentlich nur noch, ob man sich soweit einigen konnte, dass es zu einer grundlegenden Änderung oder Ergänzung des Textes im Wiki gekommen ist.

Und das scheint hier nicht der Fall zu sein. Da steht immer noch absolut eindeutig: „The oneway tag is used to indicate the access restriction on highways and other linear features for vehicles as appropriate.“

Entscheidendes Wort: FOR VEHICLES.

Das zeigt mir, dass die Diskussionen zu keinem neuen Ergebnis gekommen sind. Die Umfrage würde ich auch eher als Beleg sehen, dass die Wikidefinition weiter gültig ist. Vielen das bloß nicht klar genug ist, weil sie da wohl nicht genau lesen und vieles aus dem Bauch raus entscheiden. Das ist aber nicht der beste Weg.

Ich fand die Diskussion(enl daher eigentlich nur aus einem Aspekt heraus wirklich interessant: wie taggt man die wirklich seltenen Fälle, wo z.B. ein Fußweg für Fußgänger nur in eine Richtung erlaubt ist???
Da kommt dann nur oneway:foot in Frage, wofür glaube ich auch ein gewisser Konsens bestand TROTZ des Widerspruchs, der da enthalten ist zur Wikidefinition von oneway ... Denn wie soll man es anders auch machen?
(Es gibt einen Weg am Hauptbahnhof entlang der Europagalerie, wo tatsächlich nur in EINE Richtung ein Durchgang-Verboten-Schild für Fußgänger hängt, kann auch ein Beschilderungsfehler sein, aber da hatte ich mal das Problem.)

Noch ein Detail: bei gemeinsamem Fuß-Radwegen (oder nur bei reinen Radwegen?) sind in Deutschland außerorts so weit ich weiß auch Mofas erlaubt! Irgendsoeine Regelung gibt es jedenfalls. Ganz exakt hab ich es gerade nicht parat. Setzt du da dann oneway:bicycle, dann fallen die unter den Tisch. Mit oneway ist es da einfach präziser und umfassender, da ist die Wikidefinition ziemlich sinnvoll.

Also ich richte mich weiter nach der Wikidefinition, so lange sich die nicht ändert.

Wegen den 2 Wegen service zu track: damit hab mich noch nicht so intensiv beschäftigt. Ist wohl eine Grauzone. Im dt. Wiki steht auch: „Die Abgrenzung zu Feldwegen highway=track ist allerdings nicht eindeutig,“

Ich würde service bevorzugen, wenn es ein allgemein genutzter Weg (also z.B. auch von PKWs) z.B. zu Wanderparkplätzen ist und nicht i.d.R. nur für Landwirtschaft/Forstwirtschaft (plus Radfahrer/Fußgänger) genutzt wird. service Wege sind denke ich meist auch etwas breiter angelegt und eher so, dass zumindest notfalls auch 2 PKW aneinander vorbeikommen oder es Ausweichmöglichkeiten gibt (wenn nicht oneway ...). Und ein track ist eher ein Weg, der durch Felder/Wälder führt zu deren Bewirtschaftung, als von einer Hauptstraße zu einem festen Ziel (oder mehreren Zielen). Bei dem Weg zum Karcherhof hätte ich vielleicht auch eine Präferenz für service. Müsste mir den Weg aber auch mal anschauen.

Grüße!

Hallo tintinmaster!

Bin gerade in der Bahnhofstraße. Kleine Info: deine Änderungen bei diesem Knoten waren nicht richtig: node/2145619311/history/18 (Änderung von Nico's Diner zu Orient Kebab). In dem Gebäude ist weiterhin Nico's Diner drin, ohne Änderung. Orient Kebab ist bloß noch dazu gekommen ...

Ich korrigieren es gerade nochmal ...

Außerdem mit StreetComplete bitte aufpassen. Das entfernt ungefragt Tags wie z.B. wheelchair oder old_name, die sich in der Regel nicht ändern bei einem neuen Geschäft (oder einem leerstehenden). Dann am besten gleich nochmal hinzufügen. Oder was anderes als StreetComplete für sowas benutzen. Danke und Grüße!

Hallo Vinzenz!
Du hast auf dem Fuß-/Radweg entlang der L108 in Fechingen (der erst kürzlich gemappt wurde) oneway=yes ersetzt durch oneway:bicycle=yes (z.B. way/1474290483). Ich war da gestern auch, daher ist es mir aufgefallen.

Ich mache eine solche Änderung bei Fuß-/Radwegen immer genau umgekehrt, denn der Key oneway=* gilt generell nur für FAHRZEUGE (nicht für Fußgänger). Und oneway:bicycle=* braucht man somit nur auf Wegen, wo auch andere Fahrzeuge erlaubt sind und für Fahrräder was anderes gilt als für alle anderen (z.B. normale Einbahnststraße; Radfahren in Gegenrichtung erlaubt usw.). Hier ist der Suffix ":bicycle" schlicht überflüssig ... kann weg. oneway=yes reicht und ist OK.

Ich hoffe mal, das ist noch der aktuelle Stand der Dinge laut Wiki bzw. auf was sich die Community so geeinigt hat. Bin mir aber recht sicher ...

Ich hab es daher nochmal geändert.

Viele Grüße!

Hallo! Kleine Anmerkung: wirklich die Gebäudetypen vor Ort gecheckt? Das hier stimmte jedenfalls nicht: way/1359971934. Ist nur ein Dach vor der Haustür, keine Garage (die ist rechts daneben!). Ich ändere es gerade ... Ich checke jetzt aber nicht alle Gebäude, die du geändert hast. Hoffe, der Rest stimmt. Oder du solltest vielleicht nochmal drüber schauen vor Ort.

Viele Grüße!

Hallo! Uff ... da ist vieles wirklich die Folge von StreetComplete-Mängeln, die du verständlicherweise nicht auf den ersten Blick erkennen kannst – was ich besonders schlecht finde (von StreetComplete, nicht von dir). Siehe mein Kommentar bei anderem Änderungssatz (changeset/178368683).

Ich hab es mir auch mal in SC angeschaut, und verstehe jetzt etwas mehr, was da schief laufen kann. Es ist vieles wirklich sehr rudimentär und angezeigt wird ja sehr viel wirklich gar nicht, was vor Ort aber gemappt ist. Hätte ich so nicht gedacht ....

Wie in anderem Änderungssatz geschrieben: teste doch mal Vespucci im Parallelbetrieb zu StreetComplete – vielleicht kriegst du da neue Anregungen für das Mappen ... Oder mal SCEE („Street Complete expert edition“) statt SC ausprobieren, ist auch ein (kleiner) Schritt in Richtung Verbesserung und mehr Probleme erkennen – wobei das auch nicht vor mehr warnt als SC, aber man kann mal bei den Tags nachschauen und sich dadurch etwas schlauer machen mit der Zeit.

Und im Zweifelfall oder bei komplexeren Situationen (die man aber auch erst mal erkennen können müsste, was nicht so einfach ist, das verstehe ich auch): vielleicht doch nur eine note hinterlassen ...

Viele Grüße!

Hallo Wollte nochmal antworten ...

Ich hab mir StreetComplete nochmal etwas genauer angeschaut, und verstehe daher auch mehr, was da so passiert (z.B. dass old_name und wheelchair entfernt wird). Man kann es anders sehen … aber ich finde das nicht den besten Weg. StreetComplete macht zu viel eigenständig und ungefragt und ist daher ziemlich autoritär und will dem User zu viel an Entscheidungen abnehmen, und trifft dabei viele zweifelhafte Entscheidungen. Ich verstehe das Grundkonzept – es soll möglichst einfach sein und auch für weniger erfahrene User Spaß machen und Hemmschwelle zum Mappen senken. Das ist sicherlich begrüßenswert und im Prinzip gut … Wie du schreibst, ist es oft besser, dass etwas nicht ganz richtig oder unvollständig eingetragen ist als gar nicht und dann gilt das „Kaizen“ Prinzip – also die schrittweise, immer fortführende Verbesserung. Aber wenn es Tag entfernt, die eigentlich noch gültig sind (wie wheelchair) und der User nicht mal darauf aufmerksam gemacht wird bzw. entscheiden kann, ob das wirklich entfernt werden soll (bevor ich mir SC genauer angeschaut habe, bin ich stark davon ausgegangen, dass es das macht!), dann finde ich das ein sehr schlechtes Konzept.

Mein Ding ist das nicht, dass eine Software über meinen Kopf etwas versteckt entscheidet. Mir hat es jedenfalls über die Jahre am meisten inspiriert und Spaß gebracht, mich nach und nach in die Details des Tagging verschiedener Objekte reinzufinden und damit zu beschäftigen, was sich immer weiter verfeinert und verzweigt und erweitert mit der Zeit (am Anfang dann vielleicht nur die Objekte mappen, mit denen man sich gut genug auskennt, und den Aktionsradius dann nach und nach erweitern – das geht schnell!). Und einen Editor zu haben, der einen dabei gut unterstützt, aber nicht bevormundet. Ich kann nur raten, es doch mal mit JOSM oder Vespucci zu versuchen und deren Erweiterungsmöglichkeiten mit Styles und Presets ... Es ist ja. nicht so, dass man da ständig im Wiki nachschauen muss (was aber auch nicht schaden kann!) oder alles im Kopf haben muss, denn da gibt es ja für die allermeisten Objekte sog. Presets, die einem die wichtigsten Tags anzeigen je nach Objekt, oft mit Auswahlmöglichkeit der Tag-Werte wie in SC (nur ohne schöne Fotos usw.). Und zusätzlich hat man die Möglichkeit, Tags manuell zu ändern (was selten nötig ist). Oder schau dir mal SCEE an – die „Street Complete expert edition“ (siehe osm.wiki/SCEE)! Sieht aus und funktioniert wie SC, aber da kann man sich immerhin auch die Tags anschauen + ggf. editieren u.a.. Oder ein Tipp: installier dir doch zusätzlich noch Vespucci und nutze es mal parallel zu StreetComplete, wenn du unterwegs bist (mal den gleichen Kartenausschnitt laden, dann vor Ort vergleichen usw.) – dann sieht man, was SC vielleicht alles nicht anzeigt etc.

Noch konkret zu den Knoten:
Beim Fahrradverleih SaarRental hatte ich bereits bicycle_rental=shop angegeben. Wenn das dann irgendwo nicht richtig angezeigt wird, ist es ein bedauenswerter Mangel im Datastyling der Karte, aber korrekt getaggt. Es ist eben KEIN Fahrradladen, also kein shop=bicycle (wo Räder verkauft werden etc.).

Und zum DB Fundbüro am Hauptbahnhof Saarbrücken: da war ich gestern auch nochmal – da hast du dich auch im Raum (indoor) vertan – was du als DB Fundstelle getaggt hast, ist der Raum links NEBEN dem Fundbüro (was ich schon mal vor einiger Zeit richtig getaggt hatte, das st also schon eingetragen – als amenity=lost_property_office). Dieser Raum, denn du geändert hast, steht aber weiterhin leer (da war früher ein Fast Food – Asia DO ANH). Ich hab's geändert. Kann mir vorstellen, dass gerade solche indoor-Räume in SC nicht sehr gut dargestellt werden – das ist auch in dem meisten Editoren oft nicht gut gelöst und wird nicht sehr gut angezeigt (auch weil es beim indoor-Mapping verschiedene Etagen geben kann; JOSM hat dafür z.B. extra Erweiterungen – das ist wirklich nicht ganz unkomplex, da sollte man bei SC wirklich gut aufpassen).

Fazit: klar, kannst du weiter SC nutzen, um Sachen einzutragen, aber v.a. beim Ändern vorhandener Knoten vielleicht wirklich mehr aufpassen und SC grundsätzlich nicht blind vertrauen …

Und falls du dem SC-Entwickler etwas mitteilen willst (Issue auf GitHub), so mach das doch! Wäre sehr zu begrüßen, dass sich da etwas verbessert. Ich weiß nur nicht, wie offen der Entwickler für solche Hinweise ist. Ich hab da ehrlich gesagt etwas Zweifel … bei der grundsätzlichen „Attitude“, die StreetComplete so zeigt.

Viele Grüße!

Solche Routen scheint StreetComplete gar nicht zu unterstützen ... was aber ein gravierender Mangel ist, wenn Änderung wie foot=no an Teilstücken einer Route durch eine SC-Aufgabe gemacht werden.

Das kann man als Bug bzw. schwerwiegenen Mangel ansehen, ja ... Oder es fällt eben dem „Einfachheitskonzepts“ von StreetComplete zum Opfer und der Devise „darum sollen sich dann andere mit mehr Erfahrung kümmern“ ...

Das ist eben nicht schön – es findet eine Änderung statt, die etwas, das vorher in Ordnung war, fehlerhaft macht (in dem Fall: ungültige Wanderroute). Das ist dann keine schrittweise Verbesserung finde ich, sondern eine Verschlechterung, selbst wenn eine an einer Stelle eine tatsächlich korrekte Information hinzugefügt wurde. Also wie ein Schritt vor, und zwei zurück …

Gerade das Dumme bei solchen Routen ist, dass das dann erst mal irgendjemandem auffallen muss (denn das ist nicht so offensichtlich und wird z.B. in JOSM auch nur gemeldet, wenn man vorher etwas an einem Teilstück davon geändert hat, dass zu Problemen führt wie z.B. die StreetComplete-Änderung). D.h. ich denke, solch ein (neuer!) Fehler gerade vei Routen bleibt dann ggf. jahrelang erst mal bestehen ...

Falls du es mal melden willst an StreetComplete: nur zu, das wäre gut ... (ich habe da schon genug zu tun mit Fehlermeldungen zu Vespucci und auch JOSM). Das geht hier: https://github.com/streetcomplete/StreetComplete/issues

Viele Grüße!

Hallo!
Darf ich mal fragen, wieso du den Knoten des Restaurant gelöscht hast (statt es auf disused:amenity=restaurant zu ändern etc.)? War es ein Versehen?

Ich war heute dort; Restaurant ist geschlossen wie in SZ-Artikel beschrieben (und ein Hinweiszettel hängt an der Tür), aber komplettes Inventar und auch der Name „Tante Jenny“ sind weiterhin vorhanden; es ist also denkbar, dass ein neuer Inhaber es wiedereröffnen könnte (oder etwas anderes dort einzieht). In beiden Fällen sollte der Knoten ja wiederverwendet werden, denke ich mal ...

Ich habe ihn daher wiederhergestellt und als disused getaggt unter Beibehaltung aller weiterhin gültigen Tags.

Viele Grüße!

Hallo! Kleine Info: du hast am Zigarettenautomat vor 1 Woche check_date aktualisiert .... Ich war gerade dort. Die ref war nicht mehr aktuell, und Zahlungsweise Girokarte auch nicht mehr (jetzt girocard).

Ich ändere es gerade ....

Viele Grüße!

Hallo nochmal ...

Beim Eiscafé Toscana hast du auch old_name und wheelchair gelöscht. Warum?

Könnest du das bitte nochmal hinzufügen?

Außerdem gibt es dort noch 2 outdoor_seating Flächen, die noch name=Eiscafé Flusso haben (way/844056204 + way/844056203). Das sollte man bei einem Namenswechsel dann auch ändern ...

Und cuisine=ice_cream macht bei einem Eiscafé auch Sinn ... Jetzt ist es wie ein normales Café getaggt.

Viele Grüße!

Hallo mod22!

Hier auch eine Anmerkung ...

foot=no bei diesen Straßenabschnitten ist völlig richtig ...

Aber: das eine Stück (way/33607994) war Teil einer Hiking-Route (relation/454759), die dadurch an dieser Stelle ungültig wurde!

Ich hab das am 11.2. schon geändert (also die Wanderroute angepasst), was nicht ganz unaufwändig war.

Daher: auch bei solch auf den 1. Blick kleinen Änderungen/Ergänzungen immer sehr vorsichtig sein!

Es kommt wohl auch auf den Editor an, den man verwendet. Hat StreetComplete da keine Warnung ausgegeben (ich benutzt das nicht, weil es zu viele Fehler verursacht)? JOSM zum Beispiel hätte das gemeldet.

Viele Grüße!