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?

Hallo. Bestandteil des äußeren Umrisses sind sie auch weiterhin, da sie auf der Linie des shop-Polygons (way/37287853) liegen. Dadurch wurde das Multipolygon verzichtbar und für das tatsächlich überdachte Gebäude bleibt ein einfaches Polygon übrig, das größtenteils, aber nicht vollständig mit dem shop-Polygon übereinstimmt. Da es sich - wie du selbst sagst - um "Außenwände" handelt, halte ich darüber hinaus "barrier=wall" für inhaltlich angemessen. Von der baulichen Struktur her halte ich die beiden Bereich für nahezu identisch mit den beiden eingezäunten Bereichen (way/863572960 und way/863572959) bei dem du auch mit barrier gearbeitet hast (freilich fence statt wall, aber das macht in meinen Augen strukturell keinen Unterschied). Ich wäre eher dafür, diese beiden Bereich noch mit ins shop-Polygon einzubeziehen, zumindest soweit sie für Kunden zugänglich/relevant sind.

Yes, that looks really good indeed! :)

Hi, there have been several issues with your edits at the site of Gymnasium Hohenlimburg. I tried to solve the most urgent ones with my recent edit.

1. You removed the "building=*" tag from the main building.
2. Geometries were incorrect (i. e. building parts not connected to each other with shared nodes).
3. The name and an appropriate "amenity=*" tag is already present at the enclosing area and thus should not be repeated on every part of the building, nor on the extra node you added.

Please feel free to make further improvements. Entries are missing for all buildings for example (and I don't remember their locations good enough from my last visit to add them by myself).

Hallo. Ich habe gerade zufällig deinen Fixme-Kommentar gefunden. Ein Multipolygon war hier nicht nötig, da die Wiese hier nicht im Wald liegt, sondern neben dem Wald. Ich habe es gerade entsprechend geändert.
Dein Changeset-Kommentar sagt übrigens "meadow", aber getaggt ist die Fläche als "grassland". Falls sie zumindest gelegentlich gemäht wird, ist "landuse=meadow" zutreffender. Ansonsten ist das aktuelle "natural=grassland" korrekt.

Danke für's schnelle Ändern! Technisch sieht es jetzt sauber aus. Wie weit man da ins Detail geht und für den Park noch eine andere Darstellung findet, ist wohl auch ein bisschen Geschmacksfrage. Eine gute Alternative zum Park habe ich gerade aber auch nicht.

Hallo. Auch wenn der Changeset-Kommentar nicht mit einem Fragezeichen endet, würde ich ihn gerne mit einem freundlichen "weder, noch" beantworten. :)
Die Linie war von mir tatsächlich nur als "inner"-Element der Fußgängerzonen-Relation und umfasst absichtlich sowohl den Park als auch den Brunnen. Dementsprechend hat sie auch selber keine Tags. So, wie du es jetzt gebaut hast (und es vor meinem Umbau neulich auch war), liegen innerhalb der Fußgängerzone zwei unmittelbar benachbarte "inner"-Elemente (ein für den Park und eines für den Brunnen). Das ist technisch unsauber und führt dazu, dass die Konstruktion ggf. nicht sauber interpretiert werden kann. Siehe dazu auch die Auswertung unter http://tools.geofabrik.de/osmi/?view=areas&lon=7.01115&lat=51.44439&zoom=13

Sauberer und einfacher ist es tatsächlich, die Fußgängerzone als Relation mit nur einem "inner"-Element anzulegen und den Park sowie den Brunnen als zwei separate Elemente darin, die mit der Fußgängerzonenrelation nichts zu tun haben.

(DIsclaimer: Ich arbeite mit JOSM als Editor und weiß daher nicht genau, wie gut die Verschachtelung der Elemente im Web-Editor (iD) ersichtlich sind.)