Hallo blaubaer11, ich habe gesehen, dass du in diesem Änderungssatz die Feuerwachen in Essen neu nummeriert hast. In Änderungssatz changeset/156199081 hat User "quickstep" das zumindest für die Wache Rüttenscheid wieder auf die alte Nummer 9 geändert. Außerdem habe ich gesehen, dass du die alten "ref"-Tags unverändert gelassen hattest.

Da ich selber nicht mehr in Essen wohne, möchte ich mich da jetzt nicht einmischen und kann nicht beurteilen, was korrekt ist. Vielleicht schaut ihr zusammen noch einmal drauf, welche Nummern und Refs wohin gehören. Falls es unlösbare Unklarheiten gibt, kann ich euch ggf. einen direkten Kontakt zur Feuerwehr Essen vermitteln.

Hallo bassspieler, ich habe gesehen, dass du in diesem und weiteren Änderungssätzen jeweils die Eigenschaft "natural=wood" an diversen Flächen ergänzt hast. Das erscheint mir nicht immer sinnvoll. Zwei Beispiele:
- way/1172676125 Diese Fläche ist jetzt laut Tagging sowohl eine grasbewachsene Fläche als auch ein Wald. Das erscheint widersprüchlich, zumal schon vorher einzelne Bäume auf der Fläche explizit gemappt waren und "natural=wood" damit keine Information hinzufügt.
- way/23328331 Im Nells Park stehen gewiss viele Bäume, aber der ganze Park ist sicher kein Wald. Da gibt es noch die Rosengärten, Wiesen und den Teich in der Mitte sowieso. So wie es derzeit getaggt ist, ist die Teichfläche gleichzeitig eine Waldfläche.
Ich denke daher, dass an diesen (und möglicherweise weiteren Flächen) natural=wood wieder entfernt werden sollte.
MfG
Michael

Hallo,
nein, auf der Mailingliste bin ich nicht. Dafür bin ich zu selten in OWL, um da sinnvoll mitreden zu können.
Du meinst die kleinen Stücke südlich der Ehlenbrucher Straße, die Ohrsen zugewiesen sind? Die Grenzen gibt's in den Geobasisdaten NRW (Gemarkungen und Flure) und die Ortssatzung von Lage (https://www.lage.de/media/custom/2517_179_1.PDF?1620034818 - Karte im Anhang) bestätigt, dass diese Grenze gültig ist.
MfG
Michael

Ein Multipolygon scheint hier nicht nötig zu sein. So, wie es vor meiner Korrektur war, lagen da einfach zwei Park-Elemente übereinander (beide Elemente waren "outer", definierten also jeweils eine Außenlinie des Parks: relation/15796499/history).

Wenn tatsächlich nur der Teil westlich neben dem Krankenhausgelände Park sein soll, kann dafür einfach der Umriss als einfache Fläche gezeichnet werden.

Hallo, bei relation/14095709 gibt es eine Selbstüberschneidung der beiden Outer. Ist dir da versehentlich etwas ins Multipolygon gerutscht, was da nicht rein sollte? MfG Michael

Danke. Ich hab's mal entsprechend umgebaut und denke, dass es so jetzt auf jeden Fall besser ist.

Hallo zusammen, irgendwas stimmt hier immer noch nicht. Wir haben:
- relation/13969606 mit dem Namen "Hildener Heide", was gleichzeitig "landuse=forest" und "natural=grassland" ist;
- way/862218815 ebenfalls mit Namen "Hildener Heide" und "natural=heath", um das o. g. Relation einen sauberen Bogen macht;
- die schon ältere relation/2590898, die auch "Hildener Heide" heißt und sowohl den o. g. Way als auch die Outer-Linie der o. g. Relation umfasst.

Alle drei verweisen auf dasselbe Wikidata-Objekt und außerdem gibt es noch Geometriefehler (siehe http://tools.geofabrik.de/osmi/?view=areas&lon=7.01115&lat=51.44439&zoom=13).

Ich helfe gerne beim Aufräumen, bin aber unsicher, wie das jetzt zusammengehört. Meine Tendenz ist, dass der Name "Hildener Heide" und das Wikidata-Objekt nur an das gesamte Gebiet und nicht an die einzelnen Landuses gehört, aber diese dritte Relation finde ich dahingehend auch eher ungewöhnlich.

@KAMiKAZOW: Was genau meinst du mit dem "Farmland darunter", das noch immer Teil des Waldes ist?

Hallo. Kannst du bitte einmal prüfen, ob deine Ergänzungen zum Teutoburger Wald so vollständig und korrekt sind? Mir ist folgendes aufgefallen:

1. Die beiden Relationen relation/13646089 und relation/13646090 sind an ihrem östlichen Ende offen. Grenzrelationen sollten aber sinnvollerweise geschlossen sein.

2. Sowohl relation/13646089 als auch relation/13646091 heißen beide genau gleich ("Süd-West-Kamm Teutoburger Wald").

3. Alle drei o. g. Relationen und außerdem relation/13646092 verweisen alle auf dieselbe Wikipedia-Seite, die viel allgemeiner ist und sich nicht einmal nur mit dem Teutoburger Wald beschäftigt, geschweigedenn spezifisch mit dem jeweiligen Kamm.

MfG
Michael

Hallo László, wie schaffst du es immer, diese ganzen doppelten Punkte und kleinen Geometriefehler einzubauen? Vorgestern habe ich an der Hamburger Straße haufenweise davon aufgeräumt, jetzt ist mit diesem Changeset wieder eine große Menge doppelter Punkte nordöstlich des Hauptbahnhofs dazu gekommen.

Hallo László! In diesem Änderungssatz ist ein Multipolygon übrig geblieben, das keine inner-Mitglieder mehr hat (relation/2877272). Durch die von dir ergänzten vielen Details scheint es ohnehin nicht mehr zu stimmen. Vielleicht lässt sich das auch noch korrigieren und verbessern. MfG Michael

Hallo, danke, hatte ich auch gesehen in OSMI und beim Eintragen schon mit gerechnet, dass die Meldung kommen wird. Ist in den Quellen halt so eingezeichnet, dass die Grenze so verläuft. Ich könnte aus dem Berühungspunkt zwar zwei Punkte mit minimalem Abstand machen, damit die Meldung weg ist, aber sauber finde ich das nicht.

MfG
Michael

Hallo. Ja, sieht gut aus und es werden keine Fehler mehr angezeigt.

MfG
Michael

Hallo, die Grenze vor meiner Änderung hatte in den beteiligten Changesets keine genaue Quellenangabe. Größtenteils stimmte sie allerdings ohnehin mit den aktuellen Daten aus ALKIS (da hast du wahrscheinlich auch die Flurgrenzen nachgeschaut?) und Geobasis NRW überein. Da wo es Abweichungen gab habe ich sie korrigiert, da es mir deutlich wahrscheinlicher erscheint, dass die Grenze vor drei Jahren ungenau aus einer unklaren Quelle eingetragen wurde oder es seitdem Änderungen gab, als dass die Grenze in OSM schon immer richtig war und in ALKIS punktuell Abweichungen von 400 m bestehen.

Welche Quelle hattest du für die Level-10-Grenzen von Harsewinkel genutzt (z. B. changeset/32002151)? Gibt die Quelle zufällig auch Versmold her? :) Die Grenzen in Harsewinkel stimmen jedenfalls mit ALKIS/Geobasis überein.

MfG
Michael

PS: Schreibst du noch was im Gütersloh-Changeset? So wie es jetzt ist, möchte ich es ungerne liegenlassen (entweder alle Level-10-Grenzen rein oder Friedrichsdorf wieder raus).

Hallo. Seit dieser Änderung gibt es ein Problem mit einer doppelten Linie in der neuen Relation für den Rosengarten (siehe http://tools.geofabrik.de/osmi/?view=areas&lon=6.69916&lat=51.19318&zoom=18).
Sollte der Parkplatz ausdrücklich mit in die Fläche des Rosengartens aufgenommen werden?

MfG
Michael

PS: Deine Nachfrage hat mich zu weiterer Quellensuche angespornt: https://stadt-guetersloh.maps.arcgis.com/apps/webappviewer/index.html?id=b44478785e984e4bbad618102c34a36b
Das sieht nach den Grenzen aus ALKIS und der Geobasis NRW aus.

Das, was in der Geobasis NRW als Gemarkungen drin ist, hat aber auch nicht zwingend was mit 150 Jahre alten Grenzen zu tun, sondern berücksichtigt normalerweise alle Eingemeindungen usw. Alle aktuellen admin_level-8-Grenzen stimmen damit voll überein und auch Aufteilungen von früheren Gemeinden nach irgendwelchen Gebietsreformen sind m. E. korrekt abgebildet.
Dass die umgangssprachliche Grenzziehung eine andere ist als die amtliche, ist für mich alleine noch kein Grund, auf eine Eintragung zu verzichten. Aber wenn die von mir jetzt für Gütersloh eingetragene Grenze administrativ tatsächlich völlig irrelevant ist (oder zumindest höchst diskutabel), nehme ich sie natürlich gerne wieder raus. Was keine administrative Funktion hat, gehört auch nicht als administrative Grenze nach OSM. So ist es zum Beispiel nebenan in Verl. Die Geobasis hat da Gemarkungsgrenzen, aber die Hauptsatzung der Stadt unterscheidet gar keine Ortsteile.

(ALKIS hat übrigens noch eine weitere administrative Grenzlinie zwischen Friedrichsdorf und Avenwedde, aber die jetzt ersatzweise zu nehmen wäre geraten.)

MfG
Michael

Hallo, das ist das, was alle mir zur Verfügung stehenden Quellen (ALKIS NRW, Gemarkungsgrenzen in der Geobasis NRW, Wikipedia (OK, die zählt nicht wirklich...)) als Grenzen angeben. Stimmen auch dort sehr offensichtlich nicht mit dem tatsächlichen Siedlungsgebiet überein, aber das beobachte ich öfter. Da stimmt dann einfach die formale Zugehörigkeit nicht mit der umgangssprachlichen überein.
Falls du allerdings eine Stadtsatzung von Gütersloh mit Karte hast, die was anderes zeigt, schaue ich mir die gerne auch noch an.

MfG
Michael

Danke, ist korrigiert. Dass die Ecken knifflig waren, hatte ich schon beim Editieren gemerkt, aber der JOSM-Validator hatte mir da keine Lücken und Überschneidungen angezeigt, warum auch immer. Hätte ich dann auch erst heute in der Nachkontrolle per OSMI gefunden.

Sieht gut aus, finde ich. In 3D sieht es auf jeden Fall schon sehr ähnlich zu dem aus, wie es sein sollte: https://demo.f4map.com/#lat=51.1456665&lon=6.7549626&zoom=19

Ist es Absicht, dass bei way/867466260 die kurze Wand im Süden nicht mit drin ist?

In der Nord-Ost-Ecke habe ich die beiden niedrigeren Gebäudeteile gerade noch als separate parts eingetragen. Macht zwar mangels Höhenangaben derzeit keinen Unterschied, aber die können ja noch kommen. (Warum die in der 3D-Ansicht sogar höher als der Rest dargestellt werden, verstehe ich nicht.)

Ich kann deine Argumentation nahezu komplett nachvollziehen und sehe das fast genauso. Nur haben wir dann ein Problem, das wir beide mit unseren Lösungen nicht korrekt lösen: Wenn die beiden Bereiche ohne Dach zum Gebäude gehören, dann ist meine Lösung falsch, aber ein Multipolygon ebenso - denn ein "inner" in einem Multipolygon sagt ja eben, dass der Inhalt des inner nicht zum Rest dazu gehört. DIe komplexere Variante mit Multipolygon ist dann also zumindest auch nicht eindeutiger. Was wir stattdessen brauchen ist das building-Polygon außen rum und darin ein building:part für "Innenliegender Gebäudeteil ohne Dach", aber sowas kenne ich zumindest nicht. Wir könnten höchstens "building:part=yes + building:levels=0" nehmen. Wäre das deiner Meinung nach sachlich korrekt?