piebro/osm-data huggingface dataset:
silversurfer83 (2025-10-23 20:02:37+00:00): Hi

deine AED-Änderungen sehen "komisch" aus. Der location-Wert ist immer "Defibrillator" (das ist falsch, da soll eine gute Beschreibung des Ortes, wo er hängt, hin) und ständig löscht du sie wieder. Testest du eine App?
porfiriopaiz (2025-10-24 00:44:53+00:00): 

Hola J00SECI,

¿Podrías indicarme qué fuente de información has consultado al momento de realizar los cambios de las etiquetas de los elementos que has modificado en este conjunto de cambios?

Quiero hacer la observación de que estos elementos fueron originalmente agregados por contribuidores profesionales que en su momento han citado las fuentes de información en las cuales se han basado sus contribuciones.

¿Podrías hacer lo mismo?

Entretanto, podrías abstenerte de modificar sin fundamento alguno las contribuciones hechas por otros voluntarios.

Únicamente estás entorpeciendo el trabajo que ya han realizado.

Atentamente,
Porfirio Páiz
SoyJosueVerde (2025-11-01 03:04:16+00:00): ¿Porque borra los nodos del Portal Sur si eso es para indicar las paradas de las rutas de TM?
ghostrider44 (2025-11-02 10:14:01+00:00): Hallo Ed1tor,
schau dir mal folgende Seite an:
https://ptna.openstreetmap.de/results/DE/BW/DE-BW-VVS-Analysis.html#bus_425 
Laut Chronik hast du mit dem Änderungssatz 
https://www.openstreetmap.org/changeset/173680634 
mit dem iD-Editor Änderungen an einigen Busrelationen vorgenommen. 
Bringst du die Relationen wieder in Ordnung? Dafür ist m.E. der iD-Editor aber nicht geeignet. Ich empfehle dafür den JOSM. Den kannst du u.a. über die Seite
https://josm.openstreetmap.de/wiki/De%3AWikiStart 
holen mit dem Klick auf den Windows-Installer.
Gruß ghostrider44
Ed1tor (2025-11-03 20:05:41+00:00): Hallo ghostrider,

ja, hab an den Busrelationen was geändert, hab eine Haltestelle hinzugefügt, die bis dato nicht eingetragen war und damit offensichtlich irgendwas kaputt gemacht. Ich schaue es mir an und bringe es in Ordnung...
Gruß Editor
felipeeugenio (2025-10-23 21:28:06+00:00): Hola. ¿Cuál es la fuente de todos estos cambios?
Este tipo de cosas hay que consultarlas con la comunidad local; varios de los cambios son a nombres que ningún chileno usa ni de manera coloquial. Lo de los nombres oficiales es bastante discutible también. Vemos que hace esto en todos los paises. Por favor ingresar al chat nacional para conversar esto.
Saludos
            ---
            
            Published using OSMCha: https://osmcha.org/changesets/173680687
felipeeugenio (2025-10-24 13:20:30+00:00): Hello. No response has been given, and, in conversation with other mappers, it appears that no one actually uses the names and modifications you are using. Besides, you are only changing the name:es tag in most of the changes, which doesn't make sense.
It is really unsettling that you do this in almost every country. I hope Chile was the exception, and you really engaged the local communities in the other countries where you did these kinds of changes.

For now, I am reverting every single change you made in Chile.

Regards
porfiriopaiz (2025-10-24 00:44:38+00:00): 

Hola J00SECI,

¿Podrías indicarme qué fuente de información has consultado al momento de realizar los cambios de las etiquetas de los elementos que has modificado en este conjunto de cambios?

Quiero hacer la observación de que estos elementos fueron originalmente agregados por contribuidores profesionales que en su momento han citado las fuentes de información en las cuales se han basado sus contribuciones.

¿Podrías hacer lo mismo?

Entretanto, podrías abstenerte de modificar sin fundamento alguno las contribuciones hechas por otros voluntarios.

Únicamente estás entorpeciendo el trabajo que ya han realizado.

Atentamente,
Porfirio Páiz
ChaireMobiliteKaligrafy (2025-10-24 12:39:32+00:00): Salut!
Il y a bel et bien des pancartes Bus/Taxi/Vélo pour la voie de droite depuis un certain temps. share_busway, c'est pour ça?
martin hamel (2025-10-24 13:51:31+00:00): Allo cher ami,

Je ne les avais pas vus. Désolé. Mais ceci dit, ils sont limités dans le temps à 15h30 à 18h30 du lundi au vendredi. 

Donc si on garde le share_busway il faudrait au moins mettre cette limitation puisque la plupart du temps ce n'est pas vrai. 

https://www.google.com/maps/@45.5365202,-73.6228994,3a,19.3y,314.47h,90.45t/data=!3m7!1e1!3m5!1s6HErfvcDoefD_vZqzjlUCg!2e0!6shttps:%2F%2Fstreetviewpixels-pa.googleapis.com%2Fv1%2Fthumbnail%3Fcb_client%3Dmaps_sv.tactile%26w%3D900%26h%3D600%26pitch%3D-0.4530929865848492%26panoid%3D6HErfvcDoefD_vZqzjlUCg%26yaw%3D314.4735175545682!7i16384!8i8192?entry=ttu&g_ep=EgoyMDI1MTAyMC4wIKXMDSoASAFQAw%3D%3D
ChaireMobiliteKaligrafy (2025-10-24 14:11:56+00:00): Oui exact, il faut mettre des conditionals.
martin hamel (2025-10-24 14:20:18+00:00): Je vais le faire plus tard aujourd'hui
ChaireMobiliteKaligrafy (2025-10-24 17:31:54+00:00): cool merci!
NorthCrab_upload (2025-10-23 17:51:58+00:00): Zauważyłem, że Twoja zmiana zawiera niepoprawne adresy. Przygotowałem listę obiektów do poprawy oraz dodatkowe informacje:

Duplikat adresu w okolicy. Adres można oznaczyć na dwa sposoby: na obszarze (dokładniejsze) albo na punkcie. Aktualizując adres, należy się upewnić, czy w okolicy nie pozostały żadne duplikaty.
https://www.openstreetmap.org/node/4335555298
https://www.openstreetmap.org/way/435654011

Dokumentacja adresów (po polsku):
https://wiki.openstreetmap.org/wiki/Pl:Key:addr:*

W razie problemów lub pytań, proszę pisać. Chętnie pomogę.
Pozdrawiam! 🦀
Rafal G (2025-10-24 11:19:40+00:00): done
ManuelB701 (2025-10-23 15:53:05+00:00): Was ich eigentlich meinte ist, dass ich eine Relation für die Kaiserstraße erstelle und dadurch Fahrbahn und Bürgersteig miteinander verbinde.
NeisBot (2025-10-23 16:16:46+00:00): Based on your map edits in this changeset, I’ve drafted a suggestion for what a comment could look like: "Added public display amenity, screen details"
NeisBot (2025-10-23 16:16:46+00:00): Hi Arman Bin Alauddin, welcome to the OSM projekt and thanks for your contribution!

To make collaboration easier and help others understand your edits, it’s best to add a short description of the changes you made. Clear comments help the community follow your work and provide better feedback. You can find tips on writing good comments here[1].
---
[1] https://osm.org/wiki/Good_changeset_comments

#HelpfulComment #NoComment
porfiriopaiz (2025-10-24 00:39:50+00:00): Hola J00SECI,

¿Podrías indicarme qué fuente de información has consultado al momento de realizar los cambios de las etiquetas de los elementos que has modificado en este conjunto de cambios?

Quiero hacer la observación de que estos elementos fueron originalmente agregados por contribuidores profesionales que en su momento han citado las fuentes de información en las cuales se han basado sus contribuciones.

¿Podrías hacer lo mismo?

Entretanto, podrías abstenerte de modificar sin fundamento alguno las contribuciones hechas por otros voluntarios.

Únicamente estás entorpeciendo el trabajo que ya han realizado.

Atentamente,
Porfirio Páiz
alexwinter (2025-10-25 09:37:10+00:00): Der geschwungene Verlauf des Radweges durch den Bank Austria Park war zuvor richtig und ist mit dieser Änderung falsch. Der Park wurde vor kurzem eröffnet; alle Orthofotos sowie der offizielle Wien Stadtplan zeigen noch die gerade verlaufende Straße, die es nicht mehr gibt.
Dornbacher (2025-10-27 08:35:43+00:00): sorry & danke für Hinweis und Korrektur!
aixbrick (2025-10-24 07:34:59+00:00): Ist das ein Versehen, dass die Flächen (Parkplatz, Gras, Fußweg) alles Multipolygone sind?
vanagaudi (2025-10-25 10:42:01+00:00): Die Parkplatzfläche, die Waldfläche und die Grasfläche bilden Multipolygone nach
https://wiki.openstreetmap.org/wiki/DE:Relation:multipolygon#Mehrere_Linienz%C3%BCge_bilden_einen_Ring . Der Fußweg gehört nicht dazu. Sollte es so sein, muss ich das abchecken. Die inneren Ringe, die Grünflächen innerhalb des Parkplatzes, fehlen noch.

Ursprünglich war es so, dass die Waldfläche zugleich auch die Parkplatzfläche bedeckte. Das konnte nicht sein. Ein Multipolygon mit äußerm und innerem Ring war nicht möglich, da die südwestliche Grenzen der zwei Flächen einen gemeinsamen Abschnitt bilden.

Also habe ich in diesem Abschnitt die Grenzlinien an den Kreuzungspunkten unterbrochen, eine der beiden "verklebten" Grenzlinien gelöscht, und den verbliebenen Grenzlinien per Multiplygon den jeweiligen Flächen zugeordnet.

Konsequenterweise bin ich mit der neu hinzugekommenen Grasfläche genauso verfahren.

Mit den nicht verklebten, aber aneinander unmittelbar angrenzenden Flächen und unter Zuhilfenahme der Multipolygone lassen sich nun leichter Grenzverschiebungen, Änderungen oder neue Elemente hinzufügen.
aixbrick (2025-10-25 12:00:46+00:00): Mir ging es primär um die Flächen am Friedhofszugang (https://www.openstreetmap.org/#map=19/50.899303/6.281205).
Grundsäzlich: Wenn es kein "inner" gibt, benötigt man i.d.R. auch kein Multipolygon, sondern kann ganz normale Flächen mappen.
Das Wiki-Beispiel bezieht sich auf sehr große Flächen (wo die maximale Anzahl Nodes überschritten würde) oder wenn sich die Linien nicht überschneiden sollen. Ich vermute, es geht dir hier um letzteres.
Davon kann ich aber auch nur abraten, weil das die Komplexität, vor allem auch für andere Mapper, unnötig erhöht.  Gerade Neulinge verstehen das Prinzip nicht, was dazu führt, dass das MP beim mappen "kaputt" geht. Ich baue solche Konstrukte regelmäßig auf normale Flächen zurück, weil sie, entgegen deiner Annahme, eben nichts leichter machen.
tux67 (2025-10-25 12:25:32+00:00): Auch hier .. Volle Zustimmung @aixbrick ..
MPs die - wie in diesem Fall unnötig sing erschweren Wartung und QS über die Maßen 
Auch ich würde sowas bei Überarbeitung wieder in einem simplen und wartbaren Zustand versetzen ...
vanagaudi (2025-10-25 13:28:01+00:00): Jeder, der schon mal aneinander verklebte Flächen wegen einer Änderung trennen musste, kennt den Kampf mit den Editoren, wenn man die gemeinsam verwendeten Knoten in zwei getrennte Knoten aufdröseln muss. Je mehr Knoten betroffen sind, umso schlimmer wird es. Am Ende löschte man eine der Flächen und zeichnet sie neu.

Bei einem Multipolygon generiert man lediglich die neue Grenzlinie, löscht die nicht mehr zugehörigen Linien aus der sich ändernden Relation und fügt die neuen Grenzlinien hinzu. Alle Definitionen der stehenbleibenden Fläche bleiben dabei unberührt und werden nicht verändert.

Selbst das Erstellen einer angrenzenden Fläche geht schneller von der Hand, braucht man lediglich die hinzukommende Grenzlinie zeichnen und die zugehörigen Grenzlinien dem neuen Multipolygon hinzufügen. In der Version einer Fläche mit geschlossen umlaufender Grenzlinien müsste man jeden bestehenden Knoten der angrenzenden Fläche suchen und mit einem Knoten der neuerstellten Fläche verbinden. Wie leicht erhält man damit Lücken oder Überschneidungen wenn man einen der vorhandenen Knoten übersieht.

@aixbrick: Bei dem von dir im Kommentar oben beschriebenen Footpath handelt es sich eigentlich um eine Footway Area. Damit habe ich eine flächige Abgrenzung zum Parkplatz mit anderer Oberflächenbeschaffenheit beschrieben. Der Footpath selbst fehlte noch, der ist für das Routing und den Zugangsbeschränkungen der Tordurchgänge relevant. Ob diese Minifläche eine eigenständige Fläche ist, oder ein Multipolygon, ist mir im Prinzip egal. Die Variante mit Multipolygon konnte ich für die Gruppe aus Mauer, Parkplatz, Fußgängerbereich und Rasen schneller und einfacher realisieren.
tux67 (2025-10-25 14:26:01+00:00): Helmut - Deine subjektiv gefühlt einfachere Arbeitsweise spiegelt sich (zum Glück) nicht in der allgemeinen Lebenswirklichkeit der OSM Daten wider. Das auf "jeder" zu verallgemeinern findet zumindest schon mal bei 2 Usern, die im Umfeld mappen und QS machen kein positives Feedback. Abgeleitet von dem umgebenen Mapping das sich eher an KISS Prinzipien orientiert wird das wohl auch bei der Mehrheit der anderen Mapper im Umfeld so sein.
vanagaudi (2025-10-25 14:46:59+00:00): Kannst du mir mal die Probleme beim QS bei der Prüfung der Daten beschreiben?
tux67 (2025-10-25 14:54:51+00:00): Exemplarisch: https://www.openstreetmap.org/relation/19746341
Warum muß ein nicht komplexes rechteckiges Stückchen Gras und ein danebenliegender genauso nicht komplexer rechteckiger Parkplatz ein MP sein. Zwei separate Objekte machen den Job genauso, sind einfacher zu identifizieren, verifizieren und zu aktualisieren.
aixbrick (2025-10-25 15:07:34+00:00): Das Problem ist doch: Du (vanagaudi) weißt, wie du mit MPen umgehen musst, ein Großteil der anderen Mapper aber nicht, vor allem Neulinge. Letztere wollen vielleicht nur die Eigenschaften einer Fläche ändern und stehen vor dem Problem, dass sie zwar einzelne Wege selektieren können, aber nicht die Fläche, weil die ein eigenes Objekt ist. Entweder geben sie dann auf oder taggen einen der Wege um. Oder sie wollen nur eine Fläche löschen, löschen aber stattdessen die einzelnen Wege. Die Folge: ein MP leer, (mind.) ein anderes beschädigt. Das müssen dann andere Mapper reparieren.
Ich bitte dich daher, deine Arbeitsweise nochmal zu überdenken. Warum kompliziert, wenn es auch einfach(er) geht, siehe https://de.wikipedia.org/wiki/KISS-Prinzip.
vanagaudi (2025-10-25 15:25:29+00:00): Ich habe das anders angelegt:

1) Sieben Begrenzungslinien mit acht Knotenpunkten definiert,
2) diese Begrenzungslinien jeweils einem oder mehreren Objekten hinzugefügt:
a) Parkplatz
b) Grasfläche
c) Fußgängerfläche
d) Friedhofsmauer
Die Objekte stellen jeweils eine Relation (Multipolygon) dar.

Die andere Variante wäre:

1) Drei Flächen als Parkplatz, Grasfläche und Fußgängerfläche mit jeweils vier Knoten und vier Linien (also 12 Knoten, 12 Linien).
2) Die Friedhofsmauer mit 4 Knoten und 3 Linien.

Im Editor kann ich bei der MP-Variante jede Fläche und jede Linie einzeln identifizieren und ihre Zugehörigkeit zu den MPs bestimmen. Möchte ich eine Änderung vornehmen, kann ich schon im Voraus bestimmen, welche Auswirkungen sie haben wird.

Bei diesen Varianten versuche einmal, einen Rücksprung für die Friedhofsmauer in der Mitte des südlichen Teils einzubauen. Welche Schritte werden notwendig?
aixbrick (2025-10-25 16:04:32+00:00): Zum vorletzten Absatz: Bitte löse dich davon, dass nur du Änderungen vornimmst. Mag sein, dass die "andere Variante" bei einer Änderung 3 Klicks mehr erfordert (ich hab sie nicht gezählt ;-)), aber ich weiß, dass diese auch ein weniger versierter User bearbeiten kann.
Und am Ende sollte das das Ziel sein.
vanagaudi (2025-10-25 16:14:30+00:00): @aixbrick: Ich finde diese kleine einfache Gruppe MPs herrlich zum Einüben.

Wenn jemand Elemente dieser Gruppe editieren möchte und ein Element selektiert, so findet er zunächst nur Ways ohne jeden Inhalt aber mit dem Eintrag der Zugehörigkeit zu einer Relation. Da sollte auch ein unerfahrener Mapper schon einmal stutzig werden.

Diesen Weg als Mitglied einer oder mehrerer MPs könnte man löschen, wird aber vom Editor verhindert.

Aber man könnte eine Relation und damit eine gesamte Fläche löschen. Unter Umständen bleiben leere Ways zurück. Da schlägt aber beim Hochladen in die OSM-Datenbank das QS des Editors zu, das auf diesen Fehler hinweist. Die leeren Ways wären separat zu löschen, oder man macht seine Änderung rückgängig.

Was bleibt übrig? Man öffnet eine Relation und kann deren Eigenschaften, also die der Fläche, ändern. Unter anderem auch deren Ways löschen. Die Ways werden aber nur in dieser Relation entnommen, die anderen MPs bleiben intakt. Will man diese Änderung speichern, erhält man eine Fehlermeldung des QS, dass die Area nicht mehr über ein geschlossenes Wegesystem verfügt.

Auch dieses Problem ist lösbar, denn alle Ways dieser Relation werden im Editor farblich abgesetzt dargestellt. Die Lücke wird vom Mapper erkannt und kann durch einem neuen Way geschlossen werden, dieser muss aber manuell der MP hinzugefügt werden. Vielleicht ein Knackpunkt, den ich jedoch für nicht allzuschwierig halte. Ignoriert ein Mapper diesen Fehlerhinweis auf ein fehlendes Segment, wird die Lücke von einem Renderer auf kürzestem Wege überbrückt.

Deiner Schlussfolgerung, dass, wenn einzelne Wege gelöscht werden und damit anschließend die MP leer wäre, kann ich nicht folgen. Zumal der Editor verhindert, dass Wege gelöscht werden können, ohne das zugehörige MP zu öffnen. Selbst bei geöffnetem MP wird nur die Zugehörigkeit des Weg zu diesem MP gelöscht, nicht der Weg selbst. Der Weg selbst kann erst gelöscht werden, wenn zuvor alle Relationen zu diesem Weg entfernt wurden.
aixbrick (2025-10-26 09:04:37+00:00): Ich lade dich nach https://community.openstreetmap.org/t/zuviel-des-guten-bei-der-multipolygon-nutzung/ ein. Dort wird aktuell auch über die Verwendung von MPen diskutiert.
eggie (2025-10-23 17:38:43+00:00): Dag cassis  Ee openbaar fietspad kan niet private zijn.
Ik heb het verwijderd.
motor_vehicle=destination zou wel kunnen. Maar dat is dan niet alleen dit stukje.
MVG
eggie
limes11 (2025-10-23 19:14:59+00:00): Hallo,

das "(Bonn)" ist nicht Teil des Brückennamens. 

Schöne Grüße
GKremp (2025-10-24 10:02:15+00:00): Hallo,
das "(Bonn)" habe ich angehangen weil es in Mannheim ebenfalls eine Konrad-Adenauer-Brücke gibt.
Bitte belasse es so da ich diese Angabe zum auslesen der OSM-Abfrage brauche, Danke.
Viele Grüße
limes11 (2025-10-24 10:16:23+00:00): Hallo, 

nein, wir erfassen keine Daten für das Auslesen eines einzelnen Users. Du musst eine andere Lösung dafür finden. Z.B. im Wikipedia-Namen steht das (Bonn), damit würde ich arbeiten.

Viele Grüße
GeorgeKaplan (2025-10-31 06:37:13+00:00): Bonjour, attention ce chemin est une voie verte d'après https://www.openstreetmap.org/note/4986535 , vous l'avez ajouté comme une piste cyclable. Le wiki https://wiki.openstreetmap.org/wiki/FR:Bicycle détaille comment tagguer une voie verte.
Pèlerin Gris (2025-10-31 07:14:37+00:00): Bonjour, vous avez tout à fait raison! Et je suis impardonnable car c'est moi qui avait écrit la note... ;-)
J'ai corrigé, j'espère que c'est juste maintenant. Merci à vous!
fortera_au (2025-10-26 22:36:40+00:00): Hi, were each of these checked before making this change? It seems like you have, but an edit focused on a couple of tags and this wide often ends up being an automated edit.
            ---
            
            Published using OSMCha: https://osmcha.org/changesets/173683055
eggie (2025-10-23 17:14:38+00:00): Dag wobest..

Svp geen adresgegevens verwijderen van de kaart. Je wist de adresnodes.
Svp niet op gebouwomtrekken bijtaggen. Gebruik de adresnode.
Je edits https://overpass-api.de/achavi/?changeset=173683058
MVG
eggie
eggie (2025-10-23 17:28:28+00:00): adresgegevens hersteld
ivanbranco (2025-10-23 21:55:30+00:00): Ciao Alessandro,

qual è la fonte di questa modifica? Vedo access=yes ma non mi risulta questo cortile sia liberamente accessibile (potrei sbagliarmi). Inoltre "Stazione di Ricarica e-Bike" sembra essere una descrizione più che un nome, come segnalato più volte ai tuoi colleghi.
eggie (2025-10-23 17:34:49+00:00): Dag Peter,

chalet wordt ook gewoon gebruikt voor een heel park. Nu lijkt de hoofdtag verdwenen. 
Ik heb chalet teruggezet.
Zie wiki.. Het gaat niet over één huisje.
https://wiki.openstreetmap.org/wiki/NL:Tag:tourism%3Dchalet



MVG
eggie
peter sinot (2025-10-23 18:56:13+00:00): Ok. Ik zag chalet staan met een omschrijving van een huisje. Excuses.
eggie (2025-10-23 19:03:04+00:00): Yepp.. dat huisje zal wel weer tevoorschijn komen 😀

De tag staat gewoon op het vlak.
Het is inderdaad verwarrend dat het ook voor de aparte huisjes kan worden gebruikt en daarnaast ook voor een 'park'.
Mapse
user_5359 (2025-10-24 07:42:10+00:00): Welcome to OSM! Thanks for your addition!
The keys must be entered one per line. Incidentally, the cameras use an ALPR process.
eggie (2025-10-23 17:24:36+00:00): Expert staat op de BAG adresode
eggie (2025-10-23 17:22:46+00:00): Info samengevoegd met de adresnode. Waarom verwijder je het gebouw zelf.

MVG
eggie
eggie (2025-10-23 17:19:47+00:00): Beste  Gebruik svpmde bestaande adresnode.

Je verwijdert gewoon het hele gebouw?

Waarom?

MVG
eggie
eggie (2025-10-23 17:21:41+00:00): Gebouw hersteld Expert samengevoegd
Je edits https://overpass-api.de/achavi/?changeset=173683963

MVG
eggie
eggie (2025-10-23 17:15:53+00:00): Beste

je verwijdert nog steeds de adresnodes. Dat is belangrijke info voor de kaart om een adres te vinden. Dat werkt dus nu niet meer.

MVG
eggie
eggie (2025-10-23 17:45:21+00:00): adres hersteld.. Info samengevoegd
user_5359 (2025-10-25 08:21:04+00:00): Hello! Please have a look on https://www.osm.org/way/1444303136. What is the mean of the tag Ablution Space = yes?
Did you see the other mosque https://www.osm.org/way/375513922. Which of this buildings exists?
NittyGrittyInTheCity (2025-10-23 16:58:55+00:00): Correction: Bing Aerial Imagery, Mapillary
user_5359 (2025-10-24 07:46:46+00:00): Welcome to OSM! Thanks for your addition!

You only added the name of a business to the building, but did not note that there is also a business there. 

If you do not know the spelling of the tag, please look it up in the wiki https://wiki.osm.org.
felipeeugenio (2025-12-04 18:22:55+00:00): Hola.  El Parque, como pocos en Chile, tiene dirección. Con número y calle.
Quizás la borraste por error. La vuelvo a agregar.
Saludos
AndyB_66 (2025-10-25 14:56:12+00:00): Zabawy w testowanie proszę uskuteczniać tu: https://opengeofiction.net/ a nie na realnej mapie!
MassCartog (2025-10-23 18:44:24+00:00): Hello, welcome to OSM. The feature you removed in this changeset is valid. Please don’t remove valid OSM data.

You have a new account and might not be aware, on OSM, we do not remove features if they exist on the ground. If it exists on the ground, it is valid data regardless of a feature being public or private, designated or informal/illegal/unauthorized. Even decommissioned trails should not be removed until they no longer exist. Removing features that exist is actually considered vandalism.

It's clear that these features still exist on the ground. Not being public access areas is an invalid reason to remove data from OSM. So this edit is incorrect and damaging to valid OSM data.

The correct way to handle this is to use OSM's tagging system. access=private, or access=no would be appropriate if they are closed to the public. Once this is done, services that do use OSM data will reflect that and specify their access.
user_23428203 (2025-10-23 18:58:58+00:00): You appear to be personally defining what valid is without caring for or considering the context of reality on the ground. Maps are not reality.  The idea that open data is inherently good and that adding tags to spatial data that the lay person will not see or act on is borderline negligent. "Well intentioned" spatial data transparency is naive when coupled with lack of pragmatism and a real concern for natural resource damage. Leaning on the "blame the user not the tool" is the same old lazy logic that opponents to gun control rely on.
MassCartog (2025-10-23 19:08:57+00:00): Thanks for the reply! I'm not debating ethics. I'm letting you as a new user know what the OpenStreetMap community consensus is about removing objects that exist in reality from the OSM database. It's an action that could get your account banned. You're more than welcome to create a post on the community forum if you would like a broader discussion on the matter.

https://community.openstreetmap.org/

Please read for more info:
https://wiki.openstreetmap.org/wiki/Vandalism
Mateusz Konieczny (2025-12-09 09:23:07+00:00): Hello!

You used
crossing:markings=yesz
on https://www.openstreetmap.org/node/5556270995/history

Have you maybe meant
crossing:markings=yes
?

I am pretty sure that it is a typo, but not sure enough to just replace it (I edited some objects where situation seemed more clear to me).

Or have you used this value deliberately? In such case, what was the intended meaning?

If it is a mistake - can you fix it?
Fred_OSM (2025-12-09 10:41:50+00:00): Done with crossing:markings=zebra
Mateusz Konieczny (2026-05-27 08:57:56+00:00): it seems few more are affected: https://overpass-turbo.eu/s/2qGn
MassCartog (2025-10-23 18:37:01+00:00): Hello, welcome to OSM. In this changeset you removed trails that appear to exist on the ground. Could you explain why you have done this?

Here there are clearly trails through the woods:
https://i.imgur.com/rwusXnO.png