Multipolygon: Mehrere geschlossene outer-ways

Erlaubt ist es theoretisch.

Praktisch macht es Auswertern nur unnötigen Ärger. Beispielsweise müssen alle Member der Relation geladen werden, auch wenn nur einer der Flecken in der aktuell gerenderten Kachel ist. Auch aus anderen Gründen (z.B. Konfliktvermeidung beim Bearbeiten) sollten Multipolygone generell nicht größer sein als nötig. Und mehrere geschlossene outer fallen fast immer in die Kategorie "größer als nötig".

Nun, mein Beispiel ist gegenüber den üblichen Landuseflächen für Felder und Wälder ein Floh. 😉
Vielen dank für deine Antwort, findet man auf diese "Erlaubnis" irgendwo im Wiki einen Hinweis?

Edit: In meinen Augen kann auch für größere Flächen die Anwendung sinn machen.
Beispiel ein Wald, der von einem Fluss durchtrennt wird. Der gesamte Wald könnte aus zwei MP bestehen, aber dann muss ich jeder der Flächen auch ein Nametag geben. Damit würde es dann angeblich einen Wald 2x geben.
Über ein MP bleibt es ein Objekt mit einer Angabe des Namens (wo der dann gerendert wird, ist eine andere Sache (vlt. auf dem Fluss...lol)).
Edit2: Von allzu großen Flächen/Polygonen bin ich eh nicht begeitert... (anderes Thema 😉 )

reneman wrote:

...findet man auf diese "Erlaubnis" irgendwo im Wiki einen Hinweis?

http://wiki.openstreetmap.org/wiki/Rela … ltipolygon unter der Rubrik "Two disjunct outer rings and multiple ways forming a ring".

Andreas Binder wrote:

reneman wrote:

...findet man auf diese "Erlaubnis" irgendwo im Wiki einen Hinweis?

http://wiki.openstreetmap.org/wiki/Rela … ltipolygon unter der Rubrik "Two disjunct outer rings and multiple ways forming a ring".

Ach, dass ist das... War mir so bisher nicht bewußt gewurden... Danke.

reneman wrote:

Und es wird korrekt von Mapnik dargestellt.

Mapnik ist überaus tolerant, was unsinnige Konstrukte angeht. Daß Mapnik etwas korrekt darstellt, heißt also nichts.
Ansonsten hat Tordanik eigentlich schon alles gesagt. Dazu noch: je größer und komplizierter ein Multipolygon ist, desto fehleranfälliger wird es. Wenig versierte Mapper überblicken dann immer weniger die Tragweite einer vermeintlich einfachen Bearbeitung. Es gibt auch schlichtweg keinen vernünftigen Grund, mehrere unabhängige (also weder räumlich noch sachlich zusammenhängende) Flächen mit einem Multipolygon zu verknüpfen, auch wenn es möglich ist. In dem von Dir angegebenen Fall, wo zwei räumlich getrennte Flächen einen gemeinsamen Namen tragen, gibt es einen Sachzusammenhang. Da ist die von Dir skizzierte Lösung (MP mit u.a. name=*) schon sinnvoll.

Die korrekte Darstellung ist gar nicht so sehr das Verdienst von Mapnik, sondern von osm2pgsql. Das zerlegt diese Art von Polygonen in die Teilflächen. In der DB hat man dann 2 gleich getagte Polygone, denen man lediglich an ihrer ID ansieht, dass sie eigentlich mal ein Stück waren.
Für den Renderer ist es bei einer osm2pgsql-Datenbank eher schwierig, so importierte Dinger nicht zu rendern (z.B. um bei Grenzpolygonen grosser Orte mit kleinen Exklaven den Namen nicht mehrfach zu schreiben).

reneman wrote:

Edit: In meinen Augen kann auch für größere Flächen die Anwendung sinn machen.
Beispiel ein Wald, der von einem Fluss durchtrennt wird. Der gesamte Wald könnte aus zwei MP bestehen, aber dann muss ich jeder der Flächen auch ein Nametag geben. Damit würde es dann angeblich einen Wald 2x geben.

hi,

wie Oliver schon schrieb, mach das wohl Sinn. Ich möchte es noch etwas schärfer formulieren: Sowas macht nur Sinn, wenn die unterschiedlichen Outer wirklich ein- und dieselbe Funktion haben, quasi eine "Einheit" bilden, die nun mal auf verschiedene getrennte Flächen verteilt ist.

Ein einfaches landuse=forest mit mehreren outer reisse ich jedenfalls gnadenlos auseinander. 😉

Gruss
walter

wambacher wrote:

wie Oliver schon schrieb, mach das wohl Sinn. Ich möchte es noch etwas schärfer formulieren: Sowas macht nur Sinn, wenn die unterschiedlichen Outer wirklich ein- und dieselbe Funktion haben, quasi eine "Einheit" bilden, die nun mal auf verschiedene getrennte Flächen verteilt ist.

Hallo Walter

Dafür (eine Sache über mehrere Standorte verteilt) soll doch eigentlich die Site-Relation genutzt werden.
Wenn etwas räumlich getrennt ist, dann kann der Name auch zweimal auf einer Karte auftauchen. Wenn man den Namen nur in einer Relation hat, dann taucht der Name irgendwo auf, aber kaum da wo der Name gültig wäre.

Edbert (EvanE)

EvanE wrote:

Dafür (eine Sache über mehrere Standorte verteilt) soll doch eigentlich die Site-Relation genutzt werden.

Eine Site-Relation verwende ich manchmal, wenn innerhalb einer Area verschiedenartige Objekte liegen, die alle zusammen gehören. Hier geht es aber um reine Flächen (z.B. landuse), die mehrere outer haben. Da halte ich site für unnötig.

Gruss
walter

wambacher wrote:

EvanE wrote:

Dafür (eine Sache über mehrere Standorte verteilt) soll doch eigentlich die Site-Relation genutzt werden.

Eine Site-Relation verwende ich manchmal, wenn innerhalb einer Area verschiedenartige Objekte liegen, die alle zusammen gehören. Hier geht es aber um reine Flächen (z.B. landuse), die mehrere outer haben. Da halte ich site für unnötig.

Hallo Walter

Nun ja, es ging unter anderem um zwei Flächen (jeweils Multipolygon wegen Inner), deren einzige Gemeinsamkeit war, dass sie beide einen gleichen natural resp. landuse Wert hatten. Da halte ich das Konstrukt mit zweimal outer für fragwürdig.

Wenn zwei getrennte Flächen in ein Multipolygon (jeweils als outer) kommen sollen, finde ich, dass es schon mehr Zusammenhang bedarf als einen gleichen Wert in einem der Taggs.

Unabhängig, davon sehe ich die Verwendung von Site ähnlich wie du.

Edbert (EvanE)

Tordanik wrote:

Erlaubt ist es theoretisch.

Praktisch macht es Auswertern nur unnötigen Ärger.

+1

Es ist überflüssig, fehleranfällig und sorgt für Probleme bei der Auswertung.

bye, Nop

Aber wie wird denn nun so ein zweigeteiltes Objekt - also sowas wie der durch die neue Umgehungsstrasse geteilte "Stadtwald" - "richtig" getagged?

Gruss Christian

chkr wrote:

Aber wie wird denn nun so ein zweigeteiltes Objekt - also sowas wie der durch die neue Umgehungsstrasse geteilte "Stadtwald" - "richtig" getagged?

Hallo Christian

Das kommt immer darauf an.
Wird der Wald durch die Straße geteilt oder führt die Straße durch den Wald?

Bei einer Autobahn (min. 2x2 Spuren) oder einem Fluss würde ich sagen, das ist eine Teilung. Bei einer zweispurigen Straße oder einem Bach würde ich nicht von einer Trennung ausgehen.
Anders gesagt, wäre es bis zu einer Breite von 25-30m für mich keine Teilung, bei einer Breite von 80m oder mehr wäre es für mich eine Trennung.

Bei einer Teilung nach meiner obigen Definition würde ich in der Regel beide Teile unabhängig voneinander eintragen.
Wenn beide Teile für sich bereits 'groß' sind, stört es nicht, wenn ein Name zweimal auftaucht.
Wenn ein Teil deutlich kleiner ist als das andere, dann stört es mMn nicht, wenn der kleinere Teil keinen Namen erhält.

Edbert (EvanE)

EvanE wrote:

Das kommt immer darauf an.
Wird der Wald durch die Straße geteilt oder führt die Straße durch den Wald?

Eine öffentliche Straße (Kreis- oder Landstraße) teilt m.E. nach den Wald. Verantwortlich für dieses "Gebiet der Straße" ist die Straßenmeisterei (Winterdienst, Instandhaltung, ...) und nicht der Forst. Ein Waldweg oder eine Zufahrtsstraße zu einer WE-Siedlung würde nicht nutzen.

geri-oc wrote:

EvanE wrote:

Das kommt immer darauf an.
Wird der Wald durch die Straße geteilt oder führt die Straße durch den Wald?

Eine öffentliche Straße (Kreis- oder Landstraße) teilt m.E. nach den Wald. Verantwortlich für dieses "Gebiet der Straße" ist die Straßenmeisterei (Winterdienst, Instandhaltung, ...) und nicht der Forst. Ein Waldweg oder eine Zufahrtsstraße zu einer WE-Siedlung würde nicht nutzen.

Das kann man so sehen und erfasst dann entsprecend zwei (Teil-)Stücke.
Wie die Praxis (=OSM-Daten) zeigt, sehen aber bei weiten nicht alle das so eng.

Ich selber mache es von der breite der Schneise abhängig, die für die Straße freigehalten wird.

BTW:
Wo sollen wir dann aufhören? Bei Straßen, Eisenbahnen, Flüssen/Bächen, Stromleitungen (darunter dürfen keine Bäume sein), ...?

Edbert (EvanE)

geri-oc wrote:

EvanE wrote:

Das kommt immer darauf an.
Wird der Wald durch die Straße geteilt oder führt die Straße durch den Wald?

Eine öffentliche Straße (Kreis- oder Landstraße) teilt m.E. nach den Wald. Verantwortlich für dieses "Gebiet der Straße" ist die Straßenmeisterei (Winterdienst, Instandhaltung, ...) und nicht der Forst. Ein Waldweg oder eine Zufahrtsstraße zu einer WE-Siedlung würde nicht nutzen.

So ähnlich sehe ich das auch.

Man muß sich auch fragen: Wird die Vegetation des Waldes maßgeblich unterbrochen? Bei einfachen Waldwegen ist das selten der Fall (Baumkronen überragen den Wegverlauf, der Weg befindet sich schon daher im Wald), bei öffentlichen, befestigten Straßen nicht nur wegen deren Breite schon (da kommt noch etas Straßenrand dazu, der häufig von Bewuchs frei gehalten wird). Das ist schon eine deutliche Unterbrechung. Allerdings, wo die Grenzen genau liegen, ist doch wieder Ermessenssache und dann auch von der Bedeutung der Straße
abhängig.

Hallo,

mein Vorschlag:
Ich würde landuse einfach ab highway=tertiary und höher trennen.
Das würde auch innerorts klären welche Straßen z.B. zu landuse=residential gehören und an welchen die Flächen getrennt werden.

Grüße
Daniel

Hi,

ich denke, wir haben ein fundamentales Problem mit "landuse".

Es gibt zwei ganz unterschiedliche Dinge, die mit dem Tag "landuse" ausgedrückt wurden. Nehmen wir ein Restaurant in einem Industriegebiet:

1. Die Gebietseinteilung einer Stadt oder Gemeinde:
Das Restaurant liegt im Industriegebiet Ost.

2. Die Flächennutzung.
Die Restaurantfläche wird nicht industriell genutzt.

Beide Sichtweisen haben ihre Berechtigung und man könnte beides taggen -- aber nicht mit demselben Tag.

"landuse" war ursprünglich für die erste Auffassung gedacht, aber die zweite hat sich inzwischen durchgesetzt.

Man kann jetzt in OSM das o.g. "Industriegebiet Ost" nicht mehr taggen und das ist schade.

Weide

Weide wrote:

"landuse" war ursprünglich für die erste Auffassung gedacht, aber die zweite hat sich inzwischen durchgesetzt.

Dem würde ich widersprechen. Ich sehe es eher so daß 1 die sinnvolle und überwiegende Verwendung ist, während 2 leider von ein paar Hyperdetailmappern eingesetzt wird und die Daten eher unbrauchbar macht.

bye, Nop

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

Hi,

Nop wrote:

Dem würde ich widersprechen. Ich sehe es eher so daß 1 die sinnvolle und überwiegende Verwendung ist, während 2 leider von ein paar Hyperdetailmappern eingesetzt wird und die Daten eher unbrauchbar macht.

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.

geozeisig wrote:

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.

Hallo geozeisig,

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.

Franz

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?

geozeisig wrote:

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.

geozeisig wrote:

Ich habe auch keine direkte Beschreibung im Wiki gefunden.

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.

Weide

FvGordon wrote:

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.

Hallo Franz, geozeisig

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:

If you have one closed way making up the outer ring and it does not describe something in its own right, you may also put these tags on the outer ring and leave the relation untagged. If you have more than one outer way (see "Advanced Multipolygons" below), then this does not make sense. Therefore it is suggested (for consistency) to always put the multipolygon tags on the relation.

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.)

Edbert (EvanE)

morjak wrote:

geozeisig wrote:

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.

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.

Sehe ich wie Rockus. So kann man auch Neulinge aus "seiner" Gegend fernhalten.
Thomas

EvanE wrote:

Wird der Wald durch die Straße geteilt oder führt die Straße durch den Wald?

Bei einer Autobahn (min. 2x2 Spuren) oder einem Fluss würde ich sagen, das ist eine Teilung. Bei einer zweispurigen Straße oder einem Bach würde ich nicht von einer Trennung ausgehen.
Anders gesagt, wäre es bis zu einer Breite von 25-30m für mich keine Teilung, bei einer Breite von 80m oder mehr wäre es für mich eine Trennung.

+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.

EvanE wrote:

Bei einer Teilung nach meiner obigen Definition würde ich in der Regel beide Teile unabhängig voneinander eintragen.
Wenn beide Teile für sich bereits 'groß' sind, stört es nicht, wenn ein Name zweimal auftaucht.
Wenn ein Teil deutlich kleiner ist als das andere, dann stört es mMn nicht, wenn der kleinere Teil keinen Namen erhält.

-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)

Thomas8122 wrote:

Sehe ich wie Rockus. So kann man auch Neulinge aus "seiner" Gegend fernhalten.
Thomas

+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...)

Hi,

EvanE wrote:

Taggs gehören dann an die Relation, wenn es mehrere Outer-Wege für einen Outer-Ring gibt.

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.

Weide

Weide wrote:

EvanE wrote:

Taggs gehören dann an die Relation, wenn es mehrere Outer-Wege für einen Outer-Ring gibt.

Ich würde sagen: Tags der Multipolygonfläche gehören an das Multipolygon, denn das ist der einzige vernünftige Platz für sie.

Man kann das auch genau anders herum sehen.
Taggs gehören genau dorthin wo der einfache Mapper sie sofort sieht und nicht in einer Relation versteckt.

Es wird keinen Konsens geben, also lass uns diesen Teilaspekt hier beenden.

Edbert (EvanE)

Laut Wiki (sowohl Deutsch als auch Englisch) gehören sie an die Relation.

Baßtölpel

Basstoelpel wrote:

Laut Wiki (sowohl Deutsch als auch Englisch) gehören sie an die Relation.

Hallo Baßtölpel

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. 😬

Edbert (EvanE)

@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?

Rockus wrote:

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 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.

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.

Es sind nicht mehr Multipolygone als es "normale" Polygone wären. Und zwecks Fehlern sagt mir meine Erfahrung auch etwas anderes.

Weide wrote:

Ich würde sagen: Tags der Multipolygonfläche gehören an das Multipolygon, denn das ist der einzige vernünftige Platz für sie.

+1

EvanE wrote:

Man kann das auch genau anders herum sehen.
Taggs gehören genau dorthin wo der einfache Mapper sie sofort sieht und nicht in einer Relation versteckt.

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.

EvanE wrote:

Man kann das auch genau anders herum sehen.
Taggs gehören genau dorthin wo der einfache Mapper sie sofort sieht und nicht in einer Relation versteckt.

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.

EvanE wrote:

Es wird keinen Konsens geben, also lass uns diesen Teilaspekt hier beenden.

Wenn ich die Hoffnung aufgebe, dann höre ich bei OSM auf.

Weide

reneman wrote:

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.

Potlach hat es auch: Weg auswählen und Taste #

Ways übereinander sollte man m.E. nur bei Flächen (landuse, natural, ...) aber nicht mit highway, track, ... zusammen liegen (hatte ich am Anfang gemacht)

Wenn wir "neue" wünschen, muss es "einfach" losgehen. Und darauf kann dann "speziell" aufgebaut werden.
Wer spezielles wünscht sollte das "Aufbauprinzip" berücksichtigen:

1 = building=* | 2 = building:part=* | 3 = 3dr:...=* | 4 = ext:model=* | ....

Potlach hat es auch: Weg auswählen und Taste #

Das kann ich nicht bestätigen. Ich gehe davon aus, du meinst Potlatch2.
Für P2 steht für Taste # nix in der Shortcutliste und wenn ich übereinanderliegende Objekte/way's anklicke, erziele ich mit oder ohne Taste # keine Unterschiede. 🙁

reneman wrote:

Potlach hat es auch: Weg auswählen und Taste #

Das kann ich nicht bestätigen. Ich gehe davon aus, du meinst Potlatch2.
Für P2 steht für Taste # nix in der Shortcutliste und wenn ich übereinanderliegende Objekte/way's anklicke, erziele ich mit oder ohne Taste # keine Unterschiede. 🙁

Tastenkombinationen Tasten Strg+F = Suchfenster -> dort # eingeben und alle Stellen mit # sind markiert (oder etwas anderes im Suchfenster suchen (lassen).

P2 aufrufen -> Punkt im gemeinsamen Weg anklicken (ist mariert) -> Taste # drücken -> 1. Weg wird angezeigt -> Taste # wieder drücken -> 2. weg wird angezeigt -> usw.

geri-oc wrote:

Tastenkombinationen Tasten Strg+F = Suchfenster -> dort # eingeben und alle Stellen mit # sind markiert (oder etwas anderes im Suchfenster suchen (lassen).

P2 aufrufen -> Punkt im gemeinsamen Weg anklicken (ist mariert) -> Taste # drücken -> 1. Weg wird angezeigt -> Taste # wieder drücken -> 2. weg wird angezeigt -> usw.

Hast du dies selber in P2 ausprobiert?
Sieh mal:
-P2: http://wiki.osm.org/wiki/DE:Potlatch_2/Shortcuts
-P1: http://wiki.osm.org/wiki/DE:Potlatch/Ta … binationen

In P2 funktioniert dein beschriebener Weg bei mir nicht 🙁

für P2 heißte es "/ um einen anderen Linienzug auszuwählen, der ebenfalls diesen Punkt verwendet (hilfreich z.B. bei übereinanderliegenden Wegen; je nach Tastaturlayout muss ersatzweise der '/' bzw. '÷' des Ziffernblocks oder '-' oder '#' gedrückt werden)."

So, nun sitze ich vor einem Notebook. Das hat keinen separaten Ziffernblock (außer über zusätzlich Taste FN). Also alle Kombinationen erfolglos ausprobiert. 🙁
Tastekombintionen die statt FN die Hochstell-/Shifttaste verwenden führen erst recht nicht zum erfolg, da SHIFT einen zusätzlichen Node setzt.

Bei Potlatch innerhalb von Chrome/Mac ist es wie in der englischen Version "/", also Shift + 7. Der Trick ist, einen Punkt auszuwählen, nicht einen Pfad, Shift + 7 wählt dann einen der durch den Punkt gehenden Pfade nach dem anderem aus.

traces wrote:

Bei Potlatch innerhalb von Chrome/Mac ist es wie in der englischen Version "/", also Shift + 7. Der Trick ist, einen Punkt auszuwählen, nicht einen Pfad, Shift + 7 wählt dann einen der durch den Punkt gehenden Pfade nach dem anderem aus.

Durch Klicken mit gedrückter SHIFT-Taste (+7), erreiche ich, dass an dem betroffenen Node ein neuer Way gestartet wird. Daher die Shift-Funktion überlagert den "/" auf Taste 7.
Die Idee klang verlockend, hab es bis zum umfallen ausprobiert. Aber es geht nicht 🙁

Weide wrote:

EvanE wrote:

Es wird keinen Konsens geben, also lass uns diesen Teilaspekt hier beenden.

Wenn ich die Hoffnung aufgebe, dann höre ich bei OSM auf.

Als Perfektionist stört mich das Tagging-Chaos auch ein bisschen, aber ich habe mittlerweile akzeptiert, dass es anscheinend
nicht anders geht. 😉

geri-oc wrote:

...

P2 aufrufen -> Punkt im gemeinsamen Weg anklicken (ist mariert) -> Taste # drücken -> 1. Weg wird angezeigt -> Taste # wieder drücken -> 2. weg wird angezeigt -> usw.

reneman wrote:

für P2 heißte es "/ um einen anderen Linienzug auszuwählen, der ebenfalls diesen Punkt verwendet (hilfreich z.B. bei übereinanderliegenden Wegen; je nach Tastaturlayout muss ersatzweise der '/' bzw. '÷' des Ziffernblocks oder '-' oder '#' gedrückt werden)."

So, nun sitze ich vor einem Notebook. Das hat keinen separaten Ziffernblock (außer über zusätzlich Taste FN). Also alle Kombinationen erfolglos ausprobiert. sad
Tastekombintionen die statt FN die Hochstell-/Shifttaste verwenden führen erst recht nicht zum erfolg, da SHIFT einen zusätzlichen Node setzt.

Das brauchst du nicht

Du kannst doch einen einzelnen Punkt auswählen?
Ja, kann ich -> dann nur die Taste # drücken (falls mehrere Wege diesen Punkt benutzen)
Nein, kann ich nicht -> dann einen neuen Punkt in diese Linie einfügen ( das geht -> hast du selbst oben beschrieben und dann unter Ja weiter)

geri-oc wrote:

Du kannst doch einen einzelnen Punkt auswählen?
Ja, kann ich -> dann nur die Taste # drücken (falls mehrere Wege diesen Punkt benutzen)
Nein, kann ich nicht -> dann einen neuen Punkt in diese Linie einfügen ( das geht -> hast du selbst oben beschrieben und dann unter Ja weiter)

Das klingt jetzt fast so, als ob ich zu doof bin 😄
Aber alle vorherigen Versionen mit SHIFT, "/", "-", "#" haben weder bei Klick auf einen Punkt oder eine Linie funktioniert.
Und, du wirst es mir nicht klauben, aber genau was du auf deiner Grafik darstellst, habe ich vorhin, als es hieß "klicke auf den Node" auch probiert.
Und irgendwie wollte es vorhin nicht funktionieren. Aber ich geb ja nicht auf...
Und siehe da, Schritt-für-Schritt laut deiner Grafik, auf einmal gehts 😄
Aber eben auch NUR so, wie du es auf deiner Grafik dargestellt hast.
Mit markierten way's / Objekten geht es nicht, ausschließlich bei markiertem Node funktioniert es.
Ich werde deine super Grafik gleich mal hier verlinken. Vielen herzlichen Dank 🙂

Edit: Aber im Wiki steht ja auch: "die durch diesen Knoten gehen". Wer lesen kann, ist klar im Vorteil. Naja, hinterher ist man klüger 🙂

reneman wrote:

Ich werde deine super Grafik gleich mal hier verlinken. Vielen herzlichen Dank smile

Ist bereits drin - weil WE ist. Schönen - erholsamen Sonntagabend.

@Geri: Danke, wieder was gelernt. Bei mir funzt es.

Rockus wrote:

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

morjak wrote:

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.

Wenn man den Grundsatz "Fläche an Fläche, Grenze an Grenze" einhält, entstehen keine unübersichtlichen "Stapel". Ob ein "Stapel" aus mehreren übereinander gelagerten Relationen übersichtlicher ist???

Die "Wartung" von MP-verseuchten Gebieten ist für den Ersteller vielleicht einfach (-er), für Auswärtige ist er aber mühselig, für Neulinge abschreckend. Aber vielleicht ist letzteres ja der Zweck? Sozusagen der r-michael mit legalen Mitteln.:rolleyes:

Weide wrote:

Tags der Multipolygonfläche gehören an das Multipolygon, denn das ist der einzige vernünftige Platz für sie.

Wenn das nun so ist, würde ich gern mit operpass turbo danach suchen und es korrigieren.
Kann mal einer eine Abfrage schreiben, die nach Relation type=multipolygon sucht, wo der outer Polygon mit zB natural=water gemappt ist. ZB Tegeler See

Wer sagt, dass es so ist? Soweit ich mich erinnere hatte EvanE geschieben, dass im engl. Wiki etwas ganz anderes steht! 😛

Das war hier eigentlich ziehmlich eindeutig:

EvanE wrote:

Hallo Franz, geozeisig

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:

If you have one closed way making up the outer ring and it does not describe something in its own right, you may also put these tags on the outer ring and leave the relation untagged. If you have more than one outer way (see "Advanced Multipolygons" below), then this does not make sense. Therefore it is suggested (for consistency) to always put the multipolygon tags on the relation.

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.)

Edbert (EvanE)

geozeisig wrote:

Weide wrote:

Tags der Multipolygonfläche gehören an das Multipolygon, denn das ist der einzige vernünftige Platz für sie.

Wenn das nun so ist, würde ich gern mit operpass turbo danach suchen und es korrigieren.

Meinst Du nicht, daß Dein Pensum an unabgesprochenen Massenedits durch Deine Schlecker-Aktion vorerst erfüllt ist?

Hi,

geozeisig wrote:

Weide wrote:

Tags der Multipolygonfläche gehören an das Multipolygon, denn das ist der einzige vernünftige Platz für sie.

Wenn das nun so ist, würde ich gern mit operpass turbo danach suchen und es korrigieren.
Kann mal einer eine Abfrage schreiben, die nach Relation type=multipolygon sucht, wo der outer Polygon mit zB natural=water gemappt ist. ZB Tegeler See

Du kannst nicht einfach Sachen anderer Mapper ändern, wenn sie nicht falsch sind. Es spielt keine Rolle, ob man sie für unvernünftig, ungeschickt oder unübersichtlich hält. Und schon garnicht in einem Massenedit!

Weide

geozeisig wrote:

Weide wrote:

Tags der Multipolygonfläche gehören an das Multipolygon, denn das ist der einzige vernünftige Platz für sie.

Wenn das nun so ist, würde ich gern mit operpass turbo danach suchen und es korrigieren.
Kann mal einer eine Abfrage schreiben, die nach Relation type=multipolygon sucht, wo der outer Polygon mit zB natural=water gemappt ist. ZB Tegeler See

Es gibt keinen Grund, dies zu tun, solange nicht viele Anwendungen unter dem erlaubten Verhalten leiden.

Ganz im Gegenteil brauchen manche Anwendungen die Taggs an dem Outline. Das 3D-Rendering (z.B. OSM2World) braucht als Minimum das building=yes am Outline, sobald Building-Parts definiert sind. Das wird auch dann am Outline benötigt, wenn es sich um Multipolygone handelt (eigene unangenehme Erfahrungen).

Edbert (EvanE)

Weide wrote:

Tags der Multipolygonfläche gehören an das Multipolygon, denn das ist der einzige vernünftige Platz für sie.

reneman wrote:

Wer sagt, dass es so ist? Soweit ich mich erinnere hatte EvanE geschieben, dass im engl. Wiki etwas ganz anderes steht! 😛

Das war hier eigentlich ziehmlich eindeutig:

EvanE wrote:

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.

Hier möchte ich gern wiedersprechen: Es ist ein Unterschied, ob ein zB ein Sumpfgebiet innerhalb eines Waldes (also der Waldboden ist Sumpf), oder außerhalb des Waldes ist (im Wald ist eine Lücke, an der Sumpf ist). Erster Fall sind 2 normale Polygone, die der Renderer leichberechtigt malen sollte. Zweiteres ist zB mit einem Multipolygon lösbar.
Das gleiche gilt bei "Häuser sind im (auf dem/innerhalb) Wohngebiet" und der "See liegt im (hier aber zwischen/außerhalb) Wald".
Multipoligone sind nur dann überflüssig, wenn der Wald keinen Namen trägt und man ihn als einfache/belibige Landnutzungsfläche sieht und 2 halbe Flächen daraus macht, die den See umrahmen.

(Fortsetzung) EvanE wrote:

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:

If you have one closed way making up the outer ring and it does not describe something in its own right, you may also put these tags on the outer ring and leave the relation untagged. If you have more than one outer way (see "Advanced Multipolygons" below), then this does not make sense. Therefore it is suggested (for consistency) to always put the multipolygon tags on the relation.

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.)

Edbert (EvanE)

Im wiki Relation:multipolygon finde ich folgende Sätze:

Usage: Tags describing the multipolygon (e.g., landuse=forest) should go on the relation. The outer way(s) should be left untagged, unless they describe something in their own right.
If you have one closed way making up the outer ring and it does not describe something in its own right, you may also put these tags on the outer ring and leave the relation untagged. If you have more than one outer way (see "Advanced Multipolygons" below), then this does not make sense. Therefore it is suggested (for consistency) to always put the multipolygon tags on the relation.

-> Man sollte die Relation taggen. Aber man kann aber auch den geschlossenen outer taggen. Also falsch ist es nicht.
Von diesem Gesichtspunkt ist es unnötig, alle MP zu ändern.
Fraglich wirds, wenn beides, also Relation & outer getaggt sind. Dann sollte alles am outer für die gesamt Fläche stehen, und was am MP steht für die MP Fläche. (Beispiel: Naturschutzgebiet = Wald inkl. Lichtungen und Seen)

Tagging:It is suggested to apply all tags which describe the area to the relation, and not to the ways. In many cases this may result in completely untagged ways.
Detailed tagging:This section is for software developers, users should add tags always to relation and not to outer ways!

Ich lese da herraus, dass die Tags an die Relation gehören, bzw. dort besser aufgehoben sind. (Die andere Möglichkeit ist jedoch nicht total falsch.)

Ich plädiere dafür, geschlossene outers direkt zu taggen, sofern es nicht aus oben angeführten Gründen falsch ist. Begründung: Auch der Potlatch-User sieht dann auf einen Blick, ob eine Fläche zB forest oder water ist. Keep it easy, keep it stupid.

Pfad-Finder wrote:

Ich plädiere dafür, geschlossene outers direkt zu taggen, sofern es nicht aus oben angeführten Gründen falsch ist. Begründung: Auch der Potlatch-User sieht dann auf einen Blick, ob eine Fläche zB forest oder water ist. Keep it easy, keep it stupid.

Ich plädiere dafür, geschlossene outers direkt zu taggen, wenn man die geschlossenen outers direkt meint. Wenn man etwas anderes meint, sollte man etwas anderes taggen. Keep it easy, keep it stupid.

Weide

Weide wrote:

Pfad-Finder wrote:

Ich plädiere dafür, geschlossene outers direkt zu taggen, sofern es nicht aus oben angeführten Gründen falsch ist. Begründung: Auch der Potlatch-User sieht dann auf einen Blick, ob eine Fläche zB forest oder water ist. Keep it easy, keep it stupid.

Ich plädiere dafür, geschlossene outers direkt zu taggen, wenn man die geschlossenen outers direkt meint. Wenn man etwas anderes meint, sollte man etwas anderes taggen. Keep it easy, keep it stupid.

Weide

+1