Hallo! Bei diesem Knoten node/9978601206 sport=climbing zu entfernen, war aber nicht korrekt ... Das ist eine künstliche Kletterwand (über die gesamte Gebäudewand außen). Kann man als Knoten kartieren. Siehe engl. und deutsches Wiki ... ich ändere es nochmal ...

@Mateusz Konieczny: Small addition/idea: Maybe you could set up a second (recurring) bot that changes the cases surface=paving_stones + material=* to surface=paving_stones + paving_stones:material=*, or removes material=* if material=XYZ AND paving_stones :material=XYZ are set (and the values are the same)? And who sets a fixme or note if the 2 values are different?

This special case with the material at surface=paving_stones isn't very pretty...

I had to go there again and look for the situation (yesterday) ... And I even had to split the path ... Because half of it is surface=stepping_stones (in the grass) + material=sandstone (stepping_stones is a new value for me … I only knew it with ford=stepping_stones) and the other half is surface=paving_stones (which then gets paving_stones:material=sandstone and material=sandstone should be removed if I understood it right).

By the way: I checked another place yesterday, a large park with lots of changes by your mechanical edit (bot). And there, in 99% of all cases (> 90 ways), I had to change material=sandstone to paving_stones:material=sandstone (because it was ALWAYS surface=paving_stones – except one case where steps were a mixture of sandstone plates and granite sett – I decided to set only surface=paved here. Mixed surfaces are also not very nice to tag ...).

And other mappers here in the region have started adding surface tags to paths tagged with material=sandstone, but have NOT changed the material specification from material=sandstone to paving_stones:material=sandstone in the case of surface=paving_stones. This special case is not very pleasant and again gives rise to discussions and inconsistent tagging and perhaps necessary corrections. Not very nice ...

And this case is VERY common (with sandstone, which is very common in my region).

I checked it with Overpass-Turbo. Results of ways which consist of sandstone (from today):
– 98 ways with surface=paving_stones
– 2 ways with surface=stepping_stones

Unfortunately you can't add pictures here in changeset discussions, I could send you some from yesterday with sandstone paths/footways and steps. Or I could post them in the discussion https://community.openstreetmap.org/t/type-of-stone-in-surface-surface-granite-and-similar/9424. Should I do this?

Another note: I think the tag surface=sett will NEVER apply to a sandstone material, because sett stones are always made of of harder stone material (granite, basalt?). If sandstone, then the normal case is a "flat-machined sandstone PLATE" (larger plates or pieces of sandstone, while sett stones are normally much smaller stones). And at least here in my region you would never call a way with sandstone plates a "sett way", even if it's not 100% flat (but also the german translation of "paving stones" wouldn't be used with irregular formed sandstone plates, you would call it perhaps a "Sandsteinplattenweg" = "sandstone plates way", so I am not 100% happy with the tagging surface=paving_stones + paving_stones:material=sandstone. Here another value like surface=sandstone:plates – similar to concrete:plates – might be better in a semantic sense and easier to understand for mappers! IMHO.)

Perhaps this should have been taken into account before the mechanical edit took place ...

And I saw the discussion on community.openstreetmap.org too late – for me it goes much too fast until facts are created and a mechanical edit with a bot takes place etc. But I'm also pretty slow at following discussions, I have to admit.

Hi! After the mechanical edit that took place, I also started reviewing and adding tags to paths that have material=sandstone now.

As far as I understood, ways with surface=paving_stones should be tagged with paving_stones:surface=sandstone instead of surface=sandstone. See Wiki material=* ("For surface=paving_stones there is paving_stones:material=* tag")

Unfortunately, it is a special case (I also find it a bit strange to be honest + increases the effort). but perhaps the way way/1070794775 should be changed ... Best regards!

Es war mir nicht aufgefallen, dass dort pillar angegeben ist – ich geh da mal von einem Fehler aus. Denn ich schaue beim Editieren meist auf den Wert von fire_hydrant:position (hier lane), weil die ja manchmal falsch angegeben ist oder fehlt. Und auch, ob ein Hydrant-Knoten richtig plaziert ist (wenn ich schon vor Ort bin). Also wird es wohl mit nahezu 100% Sicherheit ein underground-Hydrant sein.

Außerdem gibt es bereits einen anderen, mit website=https://www.diejugendherbergen.de/Saarbruecken angegeben Link vom lokalen verband Verband Rheinland-Pfalz/Saar! Welcher der beiden zu bevorzugen ist, ist die Frage ...

https://www.diejugendherbergen.de/jugendherbergen/Saarbruecken/ ist wohl der lokalste Link – Verband Rheinland-Pfalz/Saar (Mitglied im DJH) – inkl. Buchungsmöglichkeit. Ich würde den bevorzugen und www.jugendherberge.de/420 ganz entfernen – denn den braucht man eigentlich nicht.

2 verschiedene Links sollte man vermeiden – das führt dann zu Validierungs-Warnungen (z.B. Osmose)! Und ist auch für User nicht sehr praktisch.

Und ich finde es auch keine gute Idee, sowohl das contact:*=* Schema UND das alte Schema für Webseite/Telefon etc. zu taggen – man sollte sich auf EINS beschränken, denke ich (Tel.Nr. ist jetzt z.B. doppelt angegeben. Ich bevorzuge das contact:*=* Schema, aber das ist wohl Geschmackssache (oder Editor-Programmierer-Geschmackssache)?

Hallo EvanE! Mir ist auch u.a. die Änderung von local_ref zu ref aufgefallen. Im Saarbrücken (oder saarVV?) scheint es eher üblich sein, für die A/B/C/...-Bushaltestellen local_ref zu verwenden, ich habe mich dem aus Gründen der Konsistenz angeschlossen. (Und es scheint mir auch passend zu sein, denn es ist ja eher KEINE im Verkehrsverbund eindeutige Identifikationsnummer für die Haltestelle wie sonst bei ref-Werten üblich.)

Jetzt ist das inkonsistent geworden, was ich nicht schön finde und verwirrend (bei einigen wird local_ref benutzt, bei den von dir geänderten ref). Ich will mich bzgl. ref/local_ref auch nicht inhaltlich positionieren, und das Wiki ist hier ja auch leider nicht wirklich klar und eindeutig. Das engl. Wiki sagt z.B. „Some people prefer to use local_ref=* for track/platform numbers, some prefer ref=*. Please note that ref=* might be in use for a network-wide unique reference of the stop position.“

Im deutschen Wiki (bei osm.wiki/DE:Tag:public_transport%3Dstop_position) steht dagegen klar: „local_ref: Bahnsteig-Nummer/Buchstabe“ – so hatte ich es mir dann eigentlich auch eingeprägt.

Und die deutsche Wiki-Seite von local_ref finde ich, wie nw520 schon in Fußnote 2 schreibt, auch etwas fragwürdig und schlecht erläutert/begründet.

Aber sollte man es allein aus Gründen der Konsistenz hier nicht wirklich bei local_ref belassen und das wieder zurück ändern? Oder falls doch etwas klar für ref spricht: dann eben wirklich einheitlich ALLE hier in der Gegend ändern?

So (inkonsistent) wie es jetzt ist, sollte es meiner Meinung nach nicht bleiben. Beispiel: node/7313009944 (ref) vs. node/1854035691 (local_ref).

Frage an dich: Was spricht für ref im Gegensatz zu local_ref – also was war überhaupt dein Grund für die Änderung?

@ Emilius123: I don't agree with your change - at least as far as the playgrounds are concerned, which I (always locally "on the ground") tagged with name="Spielplatz". I can't judge others, but I wouldn't just change them either.

I have never tagged playgrounds with name="Spielplatz" as an arbitrary descriptive name, only when there was a sign posted by the city that said "Spielplatz" - also to document that this playground does not have another unique name, as it is the case with some playgrounds here (area Saarbrücken/Germany), e.g. "Kinderspielplatz Hochstraße" (and the same kind of sign is used in both cases!).

I've added "source:name=sign" to these cases lately (e.g.: way/1153602072). You didn't remove this either, which is why there is now an Osmose error warning here: "source:name without name" - so your changes were also unclean/incomplete. And if they were consistent, you should have put a "noname=yes" as well. All in all, I don't think it's a good idea to make changes like this that aren't based on checks on the ground and without knowing the local conditions. It is a mass processing and already fulfills the definition of a mechanical processing, as others have written here - unfortunately that is the case.

And I can't see which naming convention policy is being violated here either - can you name a specific one that you feel hurt by (and explain in more detail why)?

The wiki guidelines under "Name is the name only" are in no way violated. And under "Names are not for descriptions" it even says explicitly: "Though note that some lakes are actually named 'The Lake', in such case adding it as a name is fine." (German Wiki: "Manchmal heißen Objekte tatsächlich wie ihre Kategorie, zum Beispiel gibt es Ententeiche namens 'Ententeich', oder Bundesstraßen, die 'Bundesstraße' heißen; in solchen Fällen ist es natürlich in Ordnung, diesen Namen zu verwenden.") And it is not a description either, which would then have to read, for example: "Hedge-enclosed playground with special play equipment for disabled people and picnic tables that are illuminated in the evening."

I realize this is a gray area here, but I find your overly dogmatic, simplistic application of the principle "names are not for descriptions" going too far and I would ask you to undo your changes. Some names can just be names and still be descriptive, I don't quite see why that should be a problem (assuming there is evidence such as a local sign). For example, there are also kiosks called "Kiosk" because their owners find that a sufficient name - why not put that as name=Kiosk? It isn't a "noname" object. It documents the real situation. In any case, I followed this principle. Here the city seemed to consider it sufficient to call this playgrounds "Spielplatz".

If you are not ready to undo your changes, I will reserve the right to change at least the cases I checked on site again.

If this is discussed in the community and the majority comes to a different conclusion with good arguments, and has a suggestion on how to handle these cases (e.g. with a different tag such as name:signed=Spielplatz?) I find that acceptable. But I don't think it's a good idea to make such changes without any discussion - it's too easy to overlook important aspects.

:-) Na immerhin noch in Helsinki! Wart's ab – bald ist das auf der ganzen Welt verbreitet. Großes entsteht immer im Kleinen, oder wie war das hier im Saarland?

Noch zur Ergänzung: Man hat bei OSM auch immer die Möglichkeit, eigene Werte zu "erfinden" (sie sollten nur Sinn machen) – das ist das "Any Tags you like"-Prinzip, siehe osm.wiki/Any_tags_you_like.

Statt eines Mehrfachwertes könnte man hier z.B. auch taggen: kerb=half_flush_half_lowered.

Wenn man der Meinung ist, es sollten besser nur Einzelwerte sein (wobei der Mehrfachwert eigentlich genau das aussagt, bzw. auch dann zutreffend ist, wenn es nicht exakt halb/halb ist).

Das könnte man dann mit einem Beispielfoto ins Wiki stellen – bzw. am besten vorher diskutieren, oib andere eine solche Ergänzung gutheißen, z.B. im Forum https://community.openstreetmap.org/

Falls du die Energie hast, kannst du das dort ja auch mal zur Diskussion stellen bzw. nachfragen, am besten mit einem guten Beispielfoto ...

Mir fehlt dafür mittlerweile etwas die Energie. Man muss auch mit allen möglichen, sich teils widersprechenden Antworten rechnen, wie es halt so ist ... Aber das wäre der offizielle Weg für eine allgemeine Klärung.

Also:
ich bin wohl nicht der einzige, denn ich habe es von jemand anderem übernommen, der mein Tagging dahingehend geändert hat (in Saarbrücken). Habe auch noch nie gecheckt, ob es sonstwo so benutzt wird – wobei ich auch nicht weiß, ob es solche Kanten oft sonstwo gibt. Es gibt bei OSM auch sehr oft lokale Besonderheiten, auch im Tagging ...

Also zur Klarheit: es geht um solche (neueren) Fußgängerüberwege, wo die Bordsteinkante meist weiß ist, mit tactile_paving, aber die nur ca. die Hälfte der weißen Kante ist flush und der Rest lowered. Ich weiß auch nicht genau, was die sich dabei denken ... also was der Sinn und Zweck dahinter ist. Aber das ist ein anderes Thema.

Ich hatte mich da auch anfangs für "flush" entschieden als die "geringste" Barriere, die man an einer solchen Stelle wählen kann (z.B. wenn man im Rollstuhl unterwegs ist).

Zur Notation:
Die Schreibweise mit ";" bedeutet bei einem Tag IMMER, dass mehrere Werte auftreten und das generell oder prinzipiell immer erlaubt (bzw. nur selten wirklich nicht "erlaubt" bzw. "gewünscht" – wobei es ein "nicht erlaubt" bei OSM streng genommen auch nicht gibt).

Solche „Mehrfachwerte“ sind selten wünschenswert, weil es die Auswertung, maschinelle Verarbeitung usw. erschwert. Das können auch mehr als 2 Werte sein z.B. colour="black;blue;gray“ oder traffic_sign="DE:274-30;136-10;283" (ein Tempo-30-Schild plus "Achtung Kinder" plus "Absolutes Halteverbot" untereinander).

Auf manchen Wiki-Seiten wird daher auch dringend empfohlen, nur EINEN Wert zu benutzen, bzw. das kann je nach Key verschieden sein. Und nicht immer wird auf die Möglichkeit von Mehrfachwerten hingewiesen.

Und alle Editoren haben stets die Möglichkeit, entweder eine Mehrfachauswahl zu erlauben oder nur eine Einfachauswahl. Das ist dann die Entscheidung des Programmieres des Editors (bzw. des Presets/der Vorlage für ein Objekt) ... was nicht unbedingt allgemeingültig ist.

Das ist eben das Problem ... Frage ist, ob man TROTZDEM noch die Möglichkeit hat, etwas manuell einzutragen. Bei Vespucci geht z.B. beides – der Editor bietet bei der Schnelleingabe nur eine Einfachauswahl, aber in der Detailansicht hat man die Möglichkeit, auch einen Mehrfachwert einfach hinzutippen, wie man es möchte – für Ausnahmefälle eben.

Dieses „flush;lowered“ ist sicher so ein Ausnahmefall und kommt daher auch nur selten vor – wegen Kombinatorik auch logisch, dass es deutlich seltener ist als ein Einzelwert. So ist es bei vielen solcher Mehrfachwerte. (Ich versuche übrigens Mehrfachwerte immer in alphabetischer Reihenfolge zu schreiben – also besser so als wie „lowered;flush“ – obwohl das streng genommen egal ist!)

Man muss sich hier also entscheiden: will man es wirklich KORREKT angeben wie es wirklich ist und so beschreiben, was eigentlich der Anspruch ist bei OSM (dann MUSS man „flush;lowered“ schreiben oder eben „lowered;flush“) oder will man es vereinfacht schreiben und sich für einen der beiden Werte entscheiden (Problem dabei ist z.B.: jemand anderes würde sich eher für lowered entscheiden als flush ... und es wird dann hin + her geändert – es ist einfach nicht präzise.) Daher bin ich auch dazu übergegangen und benutzte dann „flush;lowered“, um das zu vermeiden.

Und habe mir dafür z.B. auch das Preset (also die Editorvorlage) für kerb und crossings für Vespucci und JOSM angepasst, damit ich das leichter auswählen kann und nicht immer von Hand tippen muss.

Street Complete geht da eben einen sehr strengen Weg ... (und ich weiß nicht, ob man sich da etwas anpassen kann, wohl eher nicht, vermute ich).

Im Wiki fehlen solche Spezialfälle halt leider auch häufig bzw. werden nur nach und nach ergänzt, wenn es in Diskussionen zur Sprache kommt ... da geht es ja auch erst mal drum, die grundlegenden Fälle klar und eindeutig und mit Beispielfotos zu beschreiben, weil es ja schon bei den grundlegenden Werten Unklarheiten gibt (z.B.: Wo fängt raised an, wo hört lowered auf? Ab wann kann man von flush sprechen bei 0 cm oder auch bei 0,3 cm)? Was ist eigentlich rolled? und was bei einer 45° oder ca. 30° schrägen Kante, die aber nicht abgerollt/abgerundet ist??? – das tagge ich z.B. auch mit "rolled", weil sonst kein Wert gut passt + das dem am ehesten entspricht).

Da gibt es noch so einiges zu klären ... die Welt ist leider komplex und sehr vielfältig. Die strengen Einzelwerte treffen da nicht immer genau zu – werden bei OSM auch mit der Zeit oft ergänzt/erweitert oder auch neu definiert.

Das muss man immer als einen großen Prozess sehen .... und das Wiki hinkt auch oft zeitlich etwas hinterher ...

Und Editoren genauso + da entscheiden oft auch die Entwickler selbst, wie sie es haben wollen. Nicht immer sehr gut und flexibel, wie es scheint.

Ich weiß leider nicht, wie Street Complete arbeitet ... das soll ja der einfache Einstieg sein in OpenStreetMap-Bearbeitungen und einem viel abnehmen, wenn man sich noch nicht so ganz gut auskennt vielleicht.

Aber ich habe etwas den Verdacht (aber das ist nur eine Vermutung), dass da so einiges dann unter den Tisch fällt und nicht immer alles Wichtige berücksichtigt ist und das Schema, nach dem es vorgeht, sehr streng ist und nicht immer optimal bzw. sogar zu Fehlern führen kann. Das ist halt immer die Krux bei viel Automatisierung und Vereinfachung – es muss dann schon sehr ausgereift sein.

Wichtig wäre eben, dass einem trotzdem alle Tags eines Objekts und Objekte in der Umgebung angezeigt werden und man als User auch noch beurteilen kann, ob im Einzelfall etwas nicht so günstig ist und SC vielleicht daneben liegt mit dem, was es vorschlägt – ich weiß nicht, ob und wie das bei Street Complete der Fall ist. Vielleicht muss ich es mir mal anschauen ...

Das Problem betrifft aber z.T. auch andere Editoren und was eben gut auf der Karte anzeigt wird (damit es einem überhaupt auffällt) und was nicht oder nur mit einem unscheinbaren Punkt oder so – eine Sache des Renderings und „Data Stylings“.

Bei Vespucci habe ich mir das z.B. selbst noch optimiert, bei JOSM gibt es sehr viele Zusatz-Stylings, die man sich dazu aktivieren kann + man bekommt wirklich ALLE Infos ... aber es ist eben auch etwas komplexer.

Trotzdem weiterhin viel Spaß und gutes Mapping – viele kleine Ergänzungen, die man auch mit Street Complete gut machen kann, sind ja auch sehr sinnvoll ...

Und im Wiki gibt es ja auch noch viele Infos ...

Hallo! Diese Änderung von dir war aber falsch ... Der Laden dort steht immer noch leer. Farben Persch ist eins nebendran. Und bitte nicht wheelchair bei shops entfernen, auch nicht old_name ohne Grund ... Danke! Ich hab es wieder zurück geändert. Bitte immer genau die Umgebung beachten .... man übersieht ja leicht mal was ...

Da waren auch bereits Knoten von mir vorhanden mit kerb + tactile_paving (an der realen, richtigen Position der Bordsteinkante). Habe deine Tags wieder entfernt. Street Complete will die scheinbar an die Verbindungsknoten von footway=sidewalk und footway=crossing setzen .... Das ist aber nicht optimal, weil nicht die richtige Position in dem Fall. Ggf. muss man die footway-Linien dann entsprechend ändern/anpassen, damit der Punkt an der korrekten Position ist (wo eben auch die Bordsteinkante ist!), wenn man das so haben möchte. Aber doppeltes kerb/tactile_paving-Tagging sollte man auf jeden Fall vermeiden. Grüße!

Hallo! Hier war der Tag amenity=veterinary am Eingang (entrance=yes / door=hinged usw.) falsch – er ist richtig getaggt auf einem eigenen Knoten, der auf dem Gebäude liegt. Ich hatte vergessen, das am Eingang zu entfernen bzw. übersehen am 4.7.2022 ... Ich hab's daher jetzt entfernt am Eingang. Grüße!

Hallo! Hier hast du kerb + tactile_paving an einer Stelle hinzugefügt, wo an der physisch korrekten Stelle (ca. 1,6 m weiter Richtung Straße) bereits ein getaggter Knoten mit barrier=kerb, kerb=flush;lowered, tactile_paving=yes von mir war/ist (node/10727049441). 2 solche Knoten mit den gleichen Tags kurz hintereinander sollten nicht sein (z.B. für Fußgängerrouting/Warnungen für Blinde usw. – die kämen sonst doppelt). Ich hab dein Tagging daher wieder entfernt. Nicht schlimm, aber ich mach mir mit Kreuzungen und Übergängen inkl. kerb + tactile_paving immer ziemliche Arbeit und checke es vor Ort, daher bitte etwas aufpassen bei Änderungen/Ergänzungen. Danke schön!!!

(Noch was Kleines: hier ist kerb zudem flush;lowered, nicht einfach nur flush … das kommt oft in Saarbrücken vor ... Hatte mal jemand angefangen so zu taggen, wenn es so ist – ich führe das seitdem fort, auch wenn solche Doppelwerte nicht sehr schön sind – aber halt korrekt. Ich weiß nicht, ob StreetComplete das unterstützt, ich nutze nur Vespucci + JOSM.) Viele Grüße!

Hello! Please check, if tactile_paving:left and tactile_paving:right are set before setting a (probably) wrong value for tactile_paving=*. Not a big problem, but on these 2 crossings nodes, I had to remove it again (because left and right are different). And just saw it by accident ... Thank you!

Hello! That's sounds fine for me. I just changed the 3 nodes in Saarbrücken!

Unfortunately I cannot understand the discussion and the MapRoulette in Polish (I only speak German, English, a little French) – although I have (had) a great-great-grandfather from Poland - his name was Stanislaus! He was born 1874 in a small village called "Drogiszka", near "Kowalewo / Żurominek", near Plock. A little off-topic ...

But I think the discussion made sense and that government=building_control is a good value. Greetings to Poland!

Hello! Sorry for the late answer!

The tagging for these 3 nodes with government=construction_supervision was not originally my idea. It came from user nw520 (see node/6466876976) – I just adopted/copied this for the other two nodes 9139870117 and 9139823802 from node/6466876976 and didn't think further about the government=construction_supervision tag. So maybe you should ask nw520 (changeset/72112941)!

But I can say that the activity of this authority, as far as I can tell, is more of a kind of “supervision” than a direct “inspection” of new buildings (which is perhaps more the work of engineers). I think that “construction supervision” is the correct translation of “Bauaufsicht“.

See was:=**