piebro/osm-data huggingface dataset:
Zrop (2026-07-11 18:06:33+00:00): Moin silversurfer83,
ja, habe das auch schon gelesen. Jetzt scheint er das Revier gewechselt zu haben. Ich bin da vollkommen Deiner Meinung.
Kannst Du den Revert übernehmen ?

Gruß
Zrop
silversurfer83 (2026-07-11 21:21:13+00:00): Nun bin ich auch dazu gekommen mir die Änderung in OSMCha anzusehen.

Die Fragen von Zrop sind absolut valide und sollten dringend beantwortet werden.

Ein Teil der Änderungen sieht gar nicht so verkehrt aus. Leider machen die Sachen, die Fragen aufwerfen weiter Arbeit für Andere.

Erklär bitte, was das soll, was Zrop schon erwähnt hat.
            ---
            
            Published using OSMCha: https://osmcha.org/changesets/185537058
silversurfer83 (2026-07-12 08:10:07+00:00): auch hier
https://www.openstreetmap.org/changeset/185576556

Begründung:
https://www.openstreetmap.org/changeset/185543300#c1624767
ticki_52 (2026-07-12 08:14:48+00:00): Ich möchte darum bitten, die Diskussion auf die konkreten Objekte und Tags zu konzentrieren.
Abwertende Formulierungen wie „Quark“, „Mist“, „Kram“ oder Kommentare über angeblich „gewechselte Reviere“ tragen nicht zu einer fachlichen Klärung bei.
Die Fragen zu einzelnen Änderungen beantworte ich selbstverständlich, allerdings in einem zeitlich angemessenen Rahmen und auf Basis der jeweiligen Datenlage.
Bitte konzentrieren wir uns auf die einzelnen Punkte und klären sie sachlich.
silversurfer83 (2026-07-12 08:20:33+00:00): Schön, dass du dich meldest.

Dann schau dir bitte die Fragen von Zrop an. Er hat konkret Objekte verlinkt.

Nun ist der Revert durch. Die Begründung ist gegeben.

Eine Sache von mir zu deinen Landuse Anpassungen:
landuse=industrial kann auch ineinander geschachtelt werden. Da haben wir teils noch keine bessere Lösung. Sprich: Das ganze Industriegebiet bekommt ein lu=industrial und dann können, falls keine bessere Lösung vorhanden ist, einzelne Betriebe *auch* mit lu=industrial erfasst werden. Das ist nach meinem Wissen aktuell eine Möglichkeit und deshalb sollte nicht pauschal alle geschachtelten lu=ind. gelöscht werden.
silversurfer83 (2026-07-12 08:22:13+00:00): Und um weiter sachlich zu bleiben:
Du hast uns noch nicht erklärt warum du der Meinung bist, dass am Lohfelder Rüssel alle Einzelstellplätze gelöscht werden sollen. Das aber gerne in der Diskussion dort ( https://www.openstreetmap.org/changeset/184607458 )
ticki_52 (2026-07-12 09:34:28+00:00): @ silversurfer83: Deine Nachricht und Aufforderung zur Stellungnahme traf am 11. 07.26 um 21:18 Uhr bei mir ein. Am 12.07.26 um 10:30 h war der Revert durch. Dazwischen war ich noch kurz schlafen. Sieht so sachliche und konstruktive Problembewältigung aus?

Hier meine kommentare zu den von zrop genannten punkten:

11. Juli 2026 um 11:29 Uhr
Zrop (2026-07-12 12:11:17+00:00): zu 1. es handelt sich hier eindeutig um ein Wohngebiet, welches auch in ALKIS so ausgewiesen ist. Das Gebäude benötigt nicht zwingend eine Zufahrt da es direkt von der Straße/Gehweg zugänglich ist.

zu 2. die Parkfläche war nicht isoliert sondern korrekt mit "amenity=parking" + "parking=street_side" (Parkbucht) erfasst. Parkbuchten müssen nicht an Wege angebunden sein, da diese direkt von der Straße/Zufahrtsweg erreichbar sind.

zu 3. die Brücke war nicht mit "razed:bridge" erfasst, sondern korrekt mit "man_made=bridge", und sie existiert immer noch

zu 4. die Barriere ist nicht historisch sondern existiert immer noch. Es handelt sich hier um eine Reihe von Steinblöcken, die zu mindestens eine physische Sperre für den KfZ-Verkehr darstellt. Und selbst wenn diese Blöcke keine Sperre sind, ist es nicht korrekt vorhandene Objekte einfach zu löschen.
silversurfer83 (2026-07-12 14:28:07+00:00): @ticki
die Brücke als Beispiel genommen: Wenn Objekte auf allen Bildern noch klar erkennbar sind, dann werden sie mit Lebenszyklus bearbeitet und für andere OSMer eine note=* am Objekt hinterlassen.

Zu den Parkflächen: Die werden so erfasst, wie sie sind, nicht wie irgendwelche QS-Werkzeuge sie gerne hätten. Eine Tasche an der ein Weg vorbeigeht hat nur die Ausdehnung bis zur Kante. Dann muss da kein Weg mit verklebt werden. Willst du dort hin geroutet werden wird dich dein Router bis zum nächstgelegenen Punkt auf einem highway=* routen und die letzten 50cm schaffst du selbstständig. Wir verkleben keine Flächen mit highway (eine Ausnahme ist zB die hier gelöschte man_made=bridge).

Fragen?

Arbeite bitte etwas kleinteiliger, damit besser nachvollziehbar ist, was du tust. Gerne fokussiert auf ein Thema (zb *nur* eine landuse-Fläche bearbeiten). Gib gute Quellen an. Erklär, warum du etwas tust.
            ---
            
            Published using OSMCha: https://osmcha.org/changesets/185537058
ticki_52 (2026-07-13 16:44:33+00:00): Abschließende Klarstellung:  
Die vier Punkte wurden von mir bereits ausführlich beantwortet.
Die Wiederholung der selben Behauptungen durch zrop und silversurfer83 ändert nichts an den Fakten:
– Das Gebäude steht nach Mapillary 2024 isoliert im scrub, nicht in einem Wohngebiet.
– Die Parkfläche war geometrisch isoliert und ohne parking:lane‑Tag nicht erreichbar.
– Die Brücke war seit über einem Jahr als razed:bridge erfasst und existiert real nicht mehr.
– barrier=boulder ist kein gültiges OSM‑Tag; eine durchgehende Sperre ist nicht erkennbar.

Damit sind die Beanstandungen sachlich widerlegt.
Ich betrachte die Punkte als geklärt.

ticki_52
silversurfer83 (2026-07-13 17:07:37+00:00): Schön dass du dich meldest.

Ich wiederhole mich: eine Parkfläche *muss nicht* durch einen Highway angebunden sein. Sie größer zu machen, als sie ist, ist falsch.
Zrop (2026-07-13 17:40:30+00:00): - das Gebäude befindet sich auf einem ausgewiesenen und erschlossenen Wohngebiet
- beim Parkplatz hat silversurfer83 alles geschrieben
- die Brücke war nie als "razed:bridge" erfasst und existiert real!
- "barrier=boulder" wir 127x verwendet. Wenn Du es als falsch empfindest hättest Du den Wert ja ändern können
silversurfer83 (2026-07-13 17:53:18+00:00): Hi ticki, danke, dass du dich meldest.

Was Zrop sagt, sage ich auch.

Und wenn du meinst, dass wir falsch liegen, dann können wir das gerne ins Forum verlegen.
ticki_52 (2026-07-13 20:38:32+00:00): Zrop sagt: "das Gebäude befindet sich auf einem ausgewiesenen und erschlossenen Wohngebiet"
Ich sage. OSM bildet keine Liegenschaftskataster ab. Das nicht näher spezifizierte Gebäude liegt augenscheinlich inmitten eines verbuschten Geniets (Mapillary 2024)
zrop sagt: - beim Parkplatz hat silversurfer83 alles geschrieben
ich sage: Beim Tagging der am Parkplatz vorbei führenden Straße fehlte das tag "parking:left=separate". somit war der Parkplatz ein "stand alone"-Objekt und nicht mit dem Straßennetz verbunden.
Zrop sagt: - die Brücke war nie als "razed:bridge" erfasst und existiert real!" 
Ich sage: Bitte die Änderungshistorie prüfen "Version 11" vor einem Jahr
Zrop sagt: - "barrier=boulder" wir 127x verwendet. Wenn Du es als falsch empfindest hättest Du den Wert ja ändern können
Ich sage: auch mit 127 Verwendungen bleibt das Tag "barrier=boulder" im Wiki undokumentiert und seine Verwendung fragwürdig. Was wohl ein Renderer mit diesem Tag anfängt? Ich kann es mir denken: nichts. er übernimmt es einfach nicht. Also ist dieser Tag nicht verarbeitbar. Auf dem Bing-Luftbild war in dem Bereich, wo die Linie gezogen verbuschtes Gelände mit überhängendem Blattwerk "scrub". Ich meine mich erinnern zu können, dass ich einen Vermerk eingestellt hatte, dass dort eine Vor-Ort-Überprüfung erfolgen sollte.  

ticki_52
silversurfer83 (2026-07-14 03:54:53+00:00): Um das hier mal zu beenden eine Frage an Zrop:
Kennst du die Lage aus eigener Beobachtung vor Ort (survey)?
Zrop (2026-07-14 12:45:11+00:00): ja, ich kenne die Lage vor Ort, bin heute auch noch über die Brücke gefahren
silversurfer83 (2026-07-14 12:50:04+00:00): Danke.
ticki_52, damit ist die Sache für mich erstmal abgeschlossen. Survey schlägt armchair.

Ich werde den Vollrevert nicht zurücknehmen nur um dann die Spreu vom Weizen zu trennen.
ticki_52 (2026-07-14 13:00:14+00:00): Hallo Zrop,
nur zur Sicherheit: Sprechen wir über dieselbe Stelle – also die abgerissene Brücke über die Sülz in Verlängerung der Walter‑Arendt‑Straße?
Diese Brücke existiert ja nicht mehr.
Wenn du eine andere Örtlichkeit meinst, wäre eine kurze Konkretisierung hilfreich, damit wir nicht aneinander vorbeireden.
ticki_52 (2026-07-15 08:24:00+00:00): Hallo Zrop, auf meine Nachfrage, ob wir über dieselbe Örtlichkeit sprechen – nämlich die seit über einem Jahr als razed:bridge=yes erfasste und laut aktuellen Luftbildern nicht mehr existierende Fußgänger-Brücke über die Sülz in Verlängerung der Walter‑Arendt‑Straße – habe ich keine Antwort erhalten.

Damit bleibt weiterhin unklar, welche konkrete Stelle du mit deiner Aussage meintest. Eine saubere abschließende Klärung des Sachverhalts ist ohne deine Rückmeldung leider nicht möglich.
Zrop (2026-07-15 11:27:52+00:00): alle konkreten Stellen habe ich in meinem 1. Kommentar verlinkt
ticki_52 (2026-07-15 12:02:07+00:00): Hallo silversurfer83,

du hast diesen Revert mit der Begründung durchgeführt, ich hätte „hilfreiche Verbesserungen und grobe Fehler gemischt“.

Damit ich das nachvollziehen kann, bitte ich dich um eine konkrete Darstellung, welche Fehler du bei meinen Änderungen gesehen hast – insbesondere bei
– der Bereinigung und Vereinheitlichung der landuse=residential‑Flächen (u. a. Entfernen von boundary=census),
– sowie der Zusammenführung der landuse=industrial‑Flächen, die zuvor kleinteilig nach einzelnen Firmen getrennt waren.

Aus meiner Sicht waren diese Änderungen konsistent mit dem OSM‑Datenmodell und dienten der Verbesserung der Flächenstruktur in der Rösrather Innenstadt. Ein vollständiger Revert erscheint mir daher unverhältnismäßig, da er auch eindeutig korrekte Teile zurücksetzt.

Ich bitte dich daher um eine fachliche Begründung, warum ein umfassender Revert notwendig war und nicht eine selektive Korrektur der von dir als problematisch angesehenen Elemente.

Vielen Dank für deine Rückmeldung.
silversurfer83 (2026-07-15 14:53:18+00:00): Der Vollständigkeit halber der Link zur weiteren Diskussion in meinem Revert-CS:

https://www.openstreetmap.org/changeset/185576556#c1626249
            ---
            
            Published using OSMCha: https://osmcha.org/changesets/185537058
kurisubrooks (2026-07-11 15:52:47+00:00): Hello, you've deleted a ridiculous amount of detail around the WSI Cargo Precinct. I've confirmed that the features that you removed do exist, as is visible in the ESRI Imagery layer.
Can you please explain your changes?
kurisubrooks (2026-07-11 16:08:40+00:00): You also changed all aeroway=parking_position to aeroway=taxilane in the same changeset. This is not how it's done at Sydney Airport: https://www.openstreetmap.org/way/832205782
olehz (2026-07-12 15:20:47+00:00): This is a cargo terminal, which is explicitly marked on the new airport chart taking effect from the 9th. Refer to the Airservices Australia DAP. In the latest Mapbox imagery, all those tree-covered areas have been completely cleared, revealing the construction site for the new terminal. Let's wait for fresh satellite imagery to confirm. For now, what I have mapped aligns as closely as possible with the published airport diagram. As for "parking_position" — it is not a marked line like a taxiway, but rather a designated "position." I adhere to AMDB standards when denoting airport infrastructure elements; accordingly, a parking area is defined as a point or polygon, and never as a line.
Fizzie-DWG (2026-07-13 01:59:26+00:00): What are the AMDB standards that you refer to? Graeme Fitzpatrick,                                            Moderator                                                                                                                                      OSMF Data Working Group
olehz (2026-07-13 07:10:53+00:00): I'd like to provide some broader context about my edits, as this might help explain why I've been making these changes across multiple Australian airports.

I'm primarily focused on Australia right now because I'm running an experiment to implement a new airport mapping standard that aligns as closely as possible with the Aerodrome Mapping Database (AMDB) specification.

For those unfamiliar: AMDB is an international standard defined by ICAO (Annex 14 and Annex 15) and detailed in industry specifications like EUROCAE ED‑99C / RTCA DO‑272C. In simple terms, an AMDB is a structured digital dataset that describes the spatial layout of an aerodrome – runways, taxiways, parking stands, and other features – with geometry represented as points, lines, or polygons, plus attributes providing additional information. It's used to improve pilot situational awareness, surface navigation, and operational efficiency. https://skybrary.aero/articles/airport-mapping-database-amdb

To develop a solid proposal for updating OSM's airport mapping guidelines, I need to test all possible edge cases. Australia provides a great testing ground because of its diverse range of airports – from major international hubs to small regional airfields. My plan is to map all Australian airports following this AMDB‑inspired scheme, and then submit a formal proposal to the OSM community suggesting updates to the current mapping rules.

99% of my changes involve creating proper polygons for:

Taxiways (TWY), Runways (RWY), Displaced thresholds, Stopways, Blast pads, etc …
Fizzie-DWG (2026-07-13 07:19:18+00:00): & where is your Import Proposal & Organised Editing page?
Fizzie-DWG (2026-07-13 07:32:16+00:00): & no, you don't change the mapping of every airport, then present your plan, you do it the other way round!
olehz (2026-07-13 08:09:50+00:00): To produce a useful proposal, I first need to work through real edge cases. Australia is a convenient test bed for that. My intent is not to invent a parallel tagging scheme or redefine existing keys that renderers already depend on.

What I have been adding are additional geometries and tags that sit alongside the established model and should not break current rendering — for example area:aeroway=* polygons next to the usual centreline ways. Existing aeroway=runway / aeroway=taxiway ways remain the primary features.

A few practices I keep seeing (and that AMDB-style thinking highlights) are, in my view, misunderstandings rather than the OSM “standard”:

1. Runway — a runway centreline way is essential. Treating a large polygon that merges runway pavement with adjacent taxiways as aeroway=runway is not the same thing and often confuses the layout.
2. Displaced threshold / stopway — these are frequently tagged incorrectly, including by splitting the runway line into segments by surface type instead of modelling those elements properly.
3. Runway threshold nodes — these matter for operations and alignment; they are often missing or under-specified.
4. parking_position vs taxilane — a taxilane is part of the surface routing graph (a way used to move between taxiways and stands). A parking position is the stand itself: typically a node (or small area), a designated position that several taxilanes / lead-ins can connect to. It is not a marked line analogous to a taxiway. Mixing the two — e.g. tagging stand lead-ins as parking_position, or treating parking positions as linear features — confuses the graph with the stand identity. AMDB-style separation keeps graph = lines (taxiway / taxilane) and stands = points/areas (parking_position).
So the experiment is mainly about adding missing structure (polygons, thresholds, clearer separation of stopway / displaced threshold / blast pad), not ripping out the line-based scheme mappers already know.

I understand the concern about “map everything first, propose later.” I am not running an organised import of third-party geometry; this is on-the-ground / imagery-based mapping while I draft something that can be discussed properly. I will put up an Organised Editing / proposal page once the tagging pattern is stable enough to describe — trying to propose before the edge cases are clear would just produce a weak proposal.

OSM’s do-ocracy works best when experiments are visible and reversible. If particular changesets are problematic, I am happy to discuss those case by case and revert or retag where the local community prefers the previous representation.
Udarian (2026-07-11 21:37:16+00:00): Can you please double check if this is actually an ALPR as I doubt that there would be one on the fence or in a backyard like this. I am not saying that there is not anything here I just doubt that it is an ALPR, it could be a gun shot detector or just a normal security camera but if that is true the node added in this changeset is incorrectly tagged. So please either fix the position or change the tagging to more accurately tag what is actually there.

Happy mapping,
Udar.
CAM-Gerlach_Repair (2026-07-30 08:01:01+00:00): You deleted the amenity=* node, so now the actual POI for the school no longer exists. As a brand new mapper, if you don't understand why a particular object or tag exists, I'm not sure why you wouldn't just leave it alone (or actually look it up so you understand why) given it was almost certainly mapped by someone with much more experience than you.

Restored in changeset:

https://osm.org/changeset/186628868
kurisubrooks (2026-07-11 15:55:31+00:00): Hello, it appears you've realigned the boundary of the airport area to that of the inner security fence, which is not how Sydney Airport nor Bankstown Airport are mapped. Can you please explain this change?
olehz (2026-07-12 15:28:12+00:00): What I'd really like to know is why we're lumping the airport itself in with all the surrounding grass and trees. The grass can simply be mowed or burned off, so what possible reason is there for including the car park and other such areas within the airport boundary—sites that have absolutely nothing to do with airport infrastructure? The latest Mapbox imagery clearly shows a physical fence demarcating the actual premises, so why concoct spurious, artificial boundaries—unless the whole point is just to give the grass a nicer highlight on the map?
welzheimerwald (2026-07-11 13:37:59+00:00): * upsi meine natürlich changeset/165226914
CAM-Gerlach_Repair (2026-07-28 18:52:40+00:00): Same issue as changeset 186374149 and friends; see comments there:

https://osm.org/changeset/186374149
CAM-Gerlach_Repair (2026-07-29 18:02:27+00:00): Fixed yourself in changeset 186542510, thanks!

https://osm.org/changeset/186542510
CAM-Gerlach_Repair (2026-07-29 18:23:49+00:00): With some remaining cleanup by me in changeset:

https://osm.org/changeset/186602097
Anas masuris (2026-07-12 12:13:17+00:00): Hej, nie żeby coś, ale automat był już wcześniej dodany: https://www.openstreetmap.org/node/13351086084
syntex (2026-07-12 22:42:42+00:00): racja, poprawiłem
CAM-Gerlach_Repair (2026-07-30 07:57:10+00:00): This was quickly fixed, but you really shouldn't go around changing the name of high-profile landmarks in other people's countries, especially as a brand new mapper and especially in the country with the highest concentration of OSM mappers in the world. And I'm not sure why you'd somehow think you'd know better than hundreds of much more experienced, local mappers that already live here. And you can see plainly that the tower is already mapped as such, right next to this, and this is instead the clock whose name is, of course, Big Ben.
catgirlseraid (2026-07-12 11:21:01+00:00): Hi,

What are your sources for these changes? Your changeset doesn't list any.
olehz (2026-07-12 15:11:01+00:00): Airservices Australia DAP + Mapbox
aharvey (2026-07-12 22:28:35+00:00): Those charts are copyright Airservices Australia and aren't under an open license compatible with OpenStreetMap. Unless you have information to suggest otherwise, we'll need to revert these changesets. Please refrain from further edits using incompatible sources.
catgirlseraid (2026-07-12 23:04:06+00:00): As per above, do you have permission to use these charts as a source for OpenStreetMap? What about the rest of the changesets involving airports in other countries, what is the source for those?
olehz (2026-07-13 06:35:19+00:00): I understand the concern about the TWY identifiers. I acknowledge that I took those numbers from the Airservices Australia DAP charts, which are not licensed for OSM. I'm fully prepared to remove all those tags (ref=) from the ways I added.

However, I do not agree with reverting the entire geometry. All the geometry (the outlines of the taxiways, runways, aprons, etc.) was traced exclusively from Mapbox satellite imagery. Mapbox explicitly permits using their imagery for OSM tracing, so that geometry is perfectly legitimate under OSM's license.

Therefore, I propose a clean solution:

I will delete every TWY identifier that came from the charts.

The geometry drawn from Mapbox will remain intact, because it is based on a permitted source and is useful data.

A full revert would remove valid, license-compliant work and is unnecessary. If there are any other tags that you believe are problematic, please point them out and I'll remove those as well.

Please let me know if this compromise works for you. I'm happy to cooperate to keep OSM clean and legal.
olehz (2026-07-13 06:49:23+00:00): I'd like to provide some broader context about my edits, as this might help explain why I've been making these changes across multiple Australian airports.

I'm primarily focused on Australia right now because I'm running an experiment to implement a new airport mapping standard that aligns as closely as possible with the Aerodrome Mapping Database (AMDB) specification.

For those unfamiliar: AMDB is an international standard defined by ICAO (Annex 14 and Annex 15) and detailed in industry specifications like EUROCAE ED‑99C / RTCA DO‑272C. In simple terms, an AMDB is a structured digital dataset that describes the spatial layout of an aerodrome – runways, taxiways, parking stands, and other features – with geometry represented as points, lines, or polygons, plus attributes providing additional information. It's used to improve pilot situational awareness, surface navigation, and operational efficiency.

More info: https://www.eurocontrol.int/articles/aerodrome-mapping-database-amdb[reference:3]

To develop a solid proposal for updating OSM's airport mapping guidelines, I need to test all possible edge cases. Australia provides a great testing ground because of its diverse range of airports – from major international hubs to small regional airfields. My plan is to map all Australian airports following this AMDB‑inspired scheme, and then submit a formal proposal to the OSM community suggesting updates to the current mapping rules.

99% of my changes involve creating proper polygons for:

Taxiways (TWY), Runways (RWY), Displaced thresholds, Stopways, Blast pads, etc …exactly as the AMDB standard requires. This is about getting the geometry right – the spatial layout of these features – which is perfectly valid work when traced from permitted imagery like Mapbox.

I fully acknowledge that the TWY identifiers were a separate issue. Since I don't have clear records of the source for each specific case, I'm happy to remove all TWY ID tags from my edits. That eliminates the licensing concern entirely.

I hope this clarifies the bigger picture behind my edits. I'm genuinely trying to improve OSM's airport data in a thoughtful, standards‑aware way, and I'm more than willing to cooperate to resolve any licensing issues.
catgirlseraid (2026-07-13 07:55:51+00:00): "My plan is to map all Australian airports following this AMDB‑inspired scheme, and then submit a formal proposal to the OSM community suggesting updates to the current mapping rules."

Imports or mass editing should go to the community proposal stage before any changes are made, especially at scale such as this. Did you contact the Australian community prior to starting this project?

Additionally, please check that the links in future changeset comments exist, this one leads to a page not found error.

"More info: https://www.eurocontrol.int/articles/aerodrome-mapping-database-amdb[reference:3]"