Ich habe ein Gewerbegebiet: landuse=commercial
In diesem befindet sich: ein Einkaufzentrum, einige Autohändler, ein paar Werkstätten, ja sogar ein Industriebetrieb und ein Park.
Also müsste ich in (auf) diese Fläche man_made, landuse, building und … setzen. Wenn es so gemacht werden könnte (Renderer setzen die kleine Fläche in die große) - wäre alles kein Problem.
Da gibt es aber Widerspruch: Wo ein landuse ist, kann kein anderes sein. Das ist das Problem, das zur Aufteilung der (großen) landuse führt. Noch ein Problem sollte beachtet werden: die Anzahl der nodes in einer Linie wird größer.
Mitten im Wald eine Lichtung mit Wiese und in der Wiese ein See und darin eine Insel → von groß nach klein
Ja, diese Mapper machen was kaputt – keines der Industriegebiete hier ist noch gemappt.
Aber es sind nicht “Hyperdetailmapper” – es sind ganz normale Mapper, die Dinge eintragen wollen, die in OSM auch reingehören. Und das tun sie gemäß Wiki (oder quergelesenem Wiki.)
Das klassische landuse passt zu 90% der im Wiki angegebenen Werte nicht.
“Wiese”? Es gibt doch in keiner Gemeinde “Wiesengebiete”.
Nein, das klassische landuse ist tot und es kann nicht mit vertretbarem Aufwand wiederbelebt werden.
Ich bin dafür zu kapitulieren und ein neues Tag (vielleicht “designated_area”) als Ersatz für das klassische landuse zu definieren, das nur die Werte industrial, commercial, residential, forest, military und agricultural kennt und einige Dinge sehr deutlich macht:
Nichts gehört zu zwei designated_areas.
Vieles gehört aber zu gar keiner designated_area.
hier werden nur solche Gebiete erfasst, die im Bewusstsein der Bevölkerung
und/oder in der Lokalpolitik auch als Gebiete existieren.
oft haben solche Gebiete eine Bezeichnung
fast immer sind es einfache Flächen ohne irgendwelche Löcher.
im Normalfall geht es um Quadratkilometer große Flächen.
in Karten sollten sie nur bei großen Maßstäben auftauchen.
Weide
PS: Der alte Konflikt “überwiegend bewaldetes Militärgebiet” ist damit auch einfach zu lösen: designated_area=military. Es ist ein Militärgebiet. Wo da Wald ist, gibt man mit dem heutigen landuse-tag an.
Zu Multipolygon hab ich auch mal ne Frage zu Inseln:
Manche Inseln sind auf der Reit- und Wanderkarte nicht gezeichnet zB Pfaueninsel
Hier hat das äußere Polygon natural=water
würde aber im Multipolygon natural=water stehen, wie bei der Insel Werder, wäre sie zu sehen.
Ist nun die zweite Methode die bessere?
Oder muss da NOP nachbessern, und beides ist gleichwertig?
Arbeitet man mit dem Werkzeug von JOSM “Multipolygon erstellen” Strg+Alt+A so wird es auch nach der 2. Methode gestellt. Gebräuchlicher und übersichtlicher für das menschliche Auge ist aber die 1. Methode.
die Reit- und Wanderkarte macht es richtig, falsch getaggte Merkmale auch so falsch anzuzeigen - Mapnik interpretiert dieses Tagging als das eigentlich vom Ersteller geplante und zeichnet z.B. diese Pfaueninsel in die Karte ein, obwohl das Merkmal “Wasser” hier nicht vom MP ausgeschnitten wurde, denn es steht noch an der Umrisslinie und nicht am MP. JOSM macht es beim “Multipolygon erstellen” richtig.
Danke dir Franz, diese Vorschrift scheint sich aber noch nicht so weit herumgesprochen zu haben. Ich habe auch keine direkte Beschreibung im Wiki gefunden.
Ich bin aber auch noch einem anderen Form von MP begegnet: nur outer- Polylinien um eine landuse=* zu markieren.
ZB in Berlin Rummelsburg
Teilweise ist so jeder Häuserblock ein MP aus mehreren outer Linien.
Keine Frage die Renderer können damit umgehen. Ist aber extrem schwierig hier etwas hinzuzufügen / zu ändern, da man kein Überblick erhält.
In der Wiki steht auch deutlich "Für einfache Flächen empfehlen sich einfache Polygone (geschlossene Linienzüge) "
Ich frage mich nur wo da der Vorteil sein könnte und warum jemand es so macht?
Der Vorteil liegt darin, dass doppelte bzw. überlappende Flächen und Wege vermieden werden und der Datenbestand so übersichtlicher und einfacher zu warten ist. Bei aneinandergrenzenden geschlossenen Polygonen und Straßen muss man bei einer Änderung häufig erst mühselig den richtigen Weg aus dem Stapel herausfinden.
Das liegt daran, dass es nichts mit dem Multipolygon zu tun hat. Es sind die normalen Flächen, die es schon vor den Multipolygonen gab:
Wenn eine in sich geschlossene Linie ein Flächentag hat, dann ist das Objekt die gesamte von der Linie umschlossene Fläche.
Wenn also jemand an diese im MP als outer genannte Linie ein natural=water dranschreibt, dann ist da eine geschlossene Wasserfläche ohne irgendwelche Löcher. (Sie wäre auch noch da, wenn man das MP löscht.)
Es gibt nur eine Ausnahme (Ein Irrweg; bitte nicht benutzen): Wenn im MP nichts getaggt ist, dann gelten die Tags an der unter outer angegebenen Linie nicht für diese Linie sondern für das MP.
Man kann jedoch auch die Auffassung vertreten, dass eine Fläche komplett innerhalb einer größeren Fläche eindeutig ist und das entsprechend verarbeiten und darstellen. Das würde eine Menge an Multipolygonen weitgehend überflüssig machen.
Taggs gehören dann an die Relation, wenn es mehrere Outer-Wege für einen Outer-Ring gibt. Dann wären die Flächen-Taggs an den nicht geschlossenen Wegen falsch. Bei Outer-Ringen als ein geschlossenen Weg ist das nicht notwendig. In Multipolygon-Usage steht dann auch:
Damit dürfte die strikte Interpretation in der Reit- und Wanderkarte weder der Daten-Realität in OSM noch der MP-Definition entsprechen. (Die zitierte Textstelle, wurde in der deutschen Fassung dann ‘großzügig’ weggelassen.)
Aneinander grenzende Flächen haben höchstens 2 übereinander liegende Wege mit gemeinsam genutzen Knoten. Das ist nun wirklich nicht mühselig, den richtigen Way zu selektieren. Wenn man die Umrisse von Flächen nun in einzelne Ways aufteilt (die dann ohne Tags sind), unzählige Multipolygon-Relationen dazu benötigt, um diesen einzelnen Wegen wieder eine Bedeutung als Fläche zu geben, ist das alles andere als übersichtlicher. Nicht nur für Anfänger ist das deutlich schwerer zu überblicken und birgt genug zusätzliche Fehlerquellen bei der Bearbeitung in sich.
In letzter Zeit scheinen einige Mapper aber diese Herangehensweise - auch in schon gemappten Gebieten - durch Komplettumbau mit dem Ellenbogen durchzudrücken. Für mich grenzt das dann fast an Vandalismus.
+1
In einer früheren Diskussion fiel das Wort “Waldklima”.
Bei einer normalen Landstraße die durch einen Wald führt, gibt es die typischen “Gefahren” und “Vorteile”.
Baum- oder Astbruch Gefahr, mehr Wildwechsel, dunkler, schlechtere Sicht, besonders um Kurven herum, Straße länger nass/feucht. Andererseits schlechtere Aussicht auf Landschaft, schattenspendend, kühler.
Dies kann man nur Auswerten, wenn der Wald an der Straße anheftet (zB bei Wald nur an einer Seite), oder die Straße innerhalb des Waldes liegt.
-1
In einer Datenbank “stört” es schon, wenn der Name doppelt eingetragen ist. Klar, bei der gerenderten Karte nicht, aber dafür sind die Renderer zuständig. Bei den fertig gerenderten Kacheln denke ich dass es sinvoll ist, den Namen einer großen Fläche (in hohen Zoomstufen) nicht nur am Mittelpunkt einmal anzuzeigen, sondern etwa 1x pro Bildschirmbreite/-fläche. Also so ähnlich wie bei der Autobahn die “A xxx” Schilder, die sich wiederholen.
Thema Gewerbegebiet o.ä.:
Eine “Einkaufsstraße”, in der im Erdgeschoss Geschäfte sind, und in den darüberliegenden 2-5 Stockwerken Wohnungen sind, würde ich das Gebiet als landuse=retail setzten. Denn dies ist die “überwiegende” Nutzung (landuse wird/wurde als überwiegende Nutzung definiert (?)), auch wenn die Wohnungen eine größere gesammte Grundfläche einnehmen. Die Grundlokalität ist die Einkaufsstraße bzw. Einkaufsgebiet (wieder mit den jeweiligen Vor- und Nachteilen)
+1
So wie ich das sehe, ist das auch die überwiegende Meinung. Nur leider haben die vielen “kleinen Neulinge” keine Kraft/Möglichkeit/Motivation, daran was zu ändern.
(Die Unübersichtlichkeit und Fehleranfälligkeit kann natürlich auch an den Editoren liegen, dass sie es nicht “schön” darstellen…)
Ich würde sagen: Tags der Multipolygonfläche gehören an das Multipolygon, denn das ist der einzige vernünftige Platz für sie.
Es gibt aber eine historisch gewachsene Ausnahme, die man beim Rendern und beim Ändern der Arbeiten anderer Mapper kennen muss. Diese Ausnahme einzuführen war ein Fehler, weil man damit völlig überflüssigerweise die bis dahin geltende Flächenregel geändert hat und zum zweiten weil es grober Unfug ist, in den einen Datensatz zu schreiben “Es ist so und so” und dann in einen anderen Datensatz zu schreiben “Nein, doch nicht”. Aber das läßt sich jetzt eben nicht mehr ohne großen Aufwand ändern.
Hast du mein Zitat aus dem englischen Wiki in Post #28 gelesen?
Da steht nun einmal, man darf die Taggs eines geschlossenen Weges am Weg erfassen. Weil das bei mehreren Wegen, die zusammen erst einen Ring ergeben keinen Sinn machen würde (und sie dann an die Relation gehören) wird vorgeschlagen die Taggs in allen Fällen, also auch in denen, wo das nicht notwendig ist, an die Relation zu setzen.
Auf der deutschen Wiki-Seite wurde dieser Abschnitt ‘großzügig’ weggelassen.
So wird aus einer **Kann-/Soll-**Regel völlig unbeabsichtigt eine Muss-Regel.
@EvanE: Sorry, aber dafür bekommst du von mir **keine **Blumen. Dir fällt gegen 15 Uhr auf, dass etwas im deutschen Wiki fehlt. Du ergänzt die fehlende Passage nicht im deutschen Wiki, sondern beklagst dich nur darüber das es fehlt. Und wenn 6 Stunden später jemand anderes feststellt, dass es im deutschen Wiki nicht enthalten ist, bist du wieder verwundert. (kopfschüttel)
Dein Englisch ist gut genug, um die fehlende Passage korrekt zu interpretieren. Dein Hintergrundwissen übersteigt das von vielen anderen. Es wäre für jemanden wie dich kein Akt gewesen, den festgestellten Mangel sofort zu beheben. Oder hab ich da etwas übersehen?
Wenn noch eine Straße dazukommt sind wir bei 3 (was die Regel ist) und wenn dann noch ein Mapper nicht merkt, dass da schon Flächen vorhanden sind und seine eigenen noch drüber legt sind es 4. Mein gesichteter Rekord liegt bei 6. Dann viel Spaß beim Editieren und bei der Fehlersuche.
Es sind nicht mehr Multipolygone als es “normale” Polygone wären. Und zwecks Fehlern sagt mir meine Erfahrung auch etwas anderes.
Da ist es dann eher die Aufgabe der Editor-Entwickler, dafür zu sorgen, dass Tags in einer Relation nicht versteckt sind.
Das die Tags einer Fläche enthaltende Objekt, sei es nun ein geschlossener Weg oder ein Multipolygon, sollte jeweils selektiert werden, wenn man einen Punkt in der Fläche anklickt. Bei mehreren überlappenden Flächen muss es dann eben ein Auswahlmenü geben.
Wenn man einen flächenbegrenzenden Weg selektiert, sollte man jeweils auch die Möglichkeit haben, die Tags (ggf. mehrere Gruppen) für die Fläche auf der rechten oder linken Seite zu sehen und zu bearbeiten.
Im Zeitalter von Building:part wird man sich an die übereinander liegenden way’s gewöhnen müssen. Es sei den ihr wollt diese ebenfalls zerlegen
Des Weiteren bleibt festzuhalten, dass eben die erfahrenen JOSM-Mapper die geschlossene Way’s zerlegen und dafür Relationen anlegen. Und das obwohl gerade JOSM für übereinander liegende Way’s tolle Funktionen zum wechseln zwischen den way’s zur Verfügung stellt. Wenn es danach geht, müßten eigentlich die Potlatchmapper (die diese Funktion nicht haben) ein Interesse an Relationen haben.
Ich finde es nicht einfach für neue Mapper, wenn sie die Information sofort finden und dann aber immer eine Relation suchen müssen um festzustellen, ob man die Daten nicht doch anders interpretieren muss. Man sollte die einfachen Fälle (Nicht-MP-Flächen) einfach lassen, wenn man neuen Mappern entgegen kommen will.
Wenn ich die Hoffnung aufgebe, dann höre ich bei OSM auf.
weggelassen.)
