Multipolygonrelationen

Stimmt, aber das ist das kleinere Übel.
Erstmal ist es wichtig, dass das umgebene MP topologisch in Ordnung ist. Dass beim “Füllen des Loches” noch ein wenig geschummelt wird, bringt keine Software ins Schleudern.
Wenn es da drin so richtig komplex wird, kann/sollte man ein weiteres separates MP aufbauen - aber für 2-3 einfache Flächen halte ich das auch für übertrieben.

Gruss
Walter

Bezüglich der MPRelationen hatte ich den ‘Schlumpf’ mehrfach angeschrieben, aber nur auf die erste Nachricht eine Antwort erhalten:
'Multipolygone finde ich nicht übertrieben. Grade an Grenzen, wo 2 Gebiete aneinander stoßen, ist es vom Datensatz besser (nicht 2 Linien an einem Ort) und meiner Meinung nach ist damit auch angenehmer zu arbeiten (JOSM). ’
Er mappt z.B. Gebäude mit Straßen als Grenze, auch als MPRelationen (habe ich z.T. geändert). Desgleichen Spielplätze (einfaches Rechteck als MPRealtion), obwohl diese laut Bing nicht bis zur Straße reichen. Einen habe ich mal versuchsweise normal gemappt, wurde postwendend wieder rückgängig gemacht.

Bin mal gespannt, ob er sich auf meine Nachricht von vor zwei Tagen meldet. Sinngemäßer Inhalt, siehe #11 und Link auf dieses Thema.

Gruß
Josef

Es ist bei OSM ja nicht verboten, verschiedene Meinungen zu haben. Laut OSM-Religion wird sich schon irgendwann eine durchsetzen, insofern ist es auch “gewollt”, dass unterschiedliche Mapping-Stile parallel verwendet werden, das ist quasi die Abstimmung.

Ehrlich gesagt wuesste ich nicht, dass sich hier bei OSM irgendwann man irgendetwas wirklich durchgesetzt haette, die verschiednene Durcheinander kommen ja nicht von ungefaer.

Wenn man einem Mapper mit anderen Ansichten in “seinem” Revier hat (dabei ist es prinzipiell egal, welche der beiden Ansicht wahrscheinlich z.Z. die Mehrheitsmeinung darstellt), dann hat man die folgenden Moeglichkeiten:

• Man startet einen kleinen Edit-Krieg. Finde ich persoenlich nicht sonderlich sinnvoll aber auch nicht wirklich verwerflich. Denn wenn man die Verbreitung eines Mapping-Schemas als Abstimmung betrachtet, dann ist sowas ja eigentlich nur aktive Wahlbeteiligung. Mir persoenlich ist meine Freizeit fuer sowas allerdings zu schade.
• Man kann versuchen, den anderen von seiner Meinung zu ueberzeugen. Ich danke aber, man kann den Versuch auch gleich lassen, wirklich Hoffnung sehe ich da nicht.
• Man kann sich raeumlich mit ihm arangieren, d.h. man grenzt sich gegenseitig seine Gebiete ab und laesst den anderen in seinem Gebiet machen, was er will.
• Man kann sich irgendwie anders mit ihm arangieren. Ich habe in einem analogen Fall mal mit dem anderen Mapper abgemacht, dass jeder neue Objekte so eintragen kann, wie er will. Bestehende Objekte des anderen Mappers werden aber nicht “korregiert”.
• Und in diesem speiziellen Fall kann man auch noch auf die naechste API-Version hoffen, die vielleicht mal eienen echten Falechentypen mit bringt, der die ganze Diskussion sowieo obsolete macht. Ob und wan sowas kommt, kann ich alleridngs nicht beurteilen.

Gruss
Torsten

Zur Abrundung möchte ich an einem Beispiel zeigen, wie kreativ man im Bilden von MP’s sein kann:
http://www.openstreetmap.org/edit?lat=48.783832&lon=8.270092&zoom=18
kann übrigens kein Bing-Maler gewesen sein, denn dort hängt über Alt-Eberstein eine Wolke.

Einen Grundriss der Burg gibt’s hier:
http://www.burgenwelt.de/alteberstein/gr.htm

Bezüglich der Genauigkeit ist dies doch eindeutig kontraproduktiv. Und einfache Flächen per MP zu mappen ist IMHO einfach Irrsinn. Habe ja nichts gegen MPs, wenn sie erforderlich sind und übersichtlich bleiben.

BTW, darf ich Dich daran erinnern, was Du zum Thema zu komplexen MP hier geäußert hast. Der Urheber ist der Gleiche.
‘Das ist vielleicht nicht falsch (so komplizierte Konstrukte kann man ja gar nicht mehr richtig ueberblicken), aber es ist auf alle Faelle Schrott. Da duerfte kaum jemand was dagegen haben, wenn du ein bisschen aufraeumst.’

Gruß
Josef

Da brauchst du mich nicht dran zu erinnern, den uebertriebenen Gebrauch von Multipolygon-Relationen finde ich auch immer noch Scheisse. Mit meinem letzten Beitrag wollte ich dir nur aufzeigen, welche Moeglichkeiten du/man in so einer Situation hast. Auch wenn die Mehrheit der Mapper ein Verfahren nicht gut findet, so muss man sich letztendlich mit dem einen Mapper vor Ort arangieren.

Gruss
Torsten

Moin,
hier hat auch jemand das MP Konzept nicht richtig verstanden:

http://www.openstreetmap.org/browse/relation/1608666

Die Spielfelder sind aus dem Sportgelände ausgestanzt.

Chris

na ja,

beim Verschachteln von Flächen kommt nicht jeder auf den Gedanken, dass das hier nicht unbedingt notwendig ist. Immerhin hat er sich Mühe gemacht und keinen großen Murks gebaust.

Gruss
Walter

Es könnte sich auch um einen Fall von “Mappen für den Renderer” handeln.
Zumindest bei leisure=pitch innerhalb von leisure=sports_centre werden (oder zumindest wurden früher) die Spielfelder durch das Sportcenter verdeckt.
Obwohl der outer mit leisure=track sowieso etwas fragwürdig ist.

Grüsse

mdk

Ja, ich werde das bei Gelegenheit verbessern:

Gelände: leisure=sports_centre, sport=multi, name=Sportgelände XYZ

SpielFelder: leisure=pitch, sport=soccer

** alles ohne MP **

Es geht auch ohne MP (Ein sogenanntes C-Shape):

http://www.openstreetmap.org/browse/way/115602395

Chris

AUA, das tut weh!!!

Eine Linie so “malen” (*), dass die Fläche in der Grafik trotzdem richtig aussieht.
Hat mit der Realität nicht zu tun, weil an der “Nahtstelle” eben nicht zwei Flächen aneinander grenzen, sondern es sich hier um eine Fläche handelt.

Gruss
Walter

(*) Das Wort “zeichnen” kann ich hier beim besten Willen nicht verwenden.

Im Gegensatz dazu finde ich das gar nicht schlimm:

• Die Eintragung verstoest gegen keine der (ohnehin nur sehr schwammigen) OSM-Regeln.
• Wenn man die Flaeche erfassen will, dann kommt es wirklich auch nur auf die Flaeche drauf an und nicht auf die Randlinie. Und die Abmessungend er Flaeche sind hier ja vollkommen korrekt. Wenn sich eine Auswertung auf die Raender von einzelenen FLaechenelementen stuetzt, ist sie sowieso zum scheitern verurteilt (Problem: Bei OSM gibt es z.Z. keine klare Unterscheidung zwischen Flaeche und Linie.)
• “Kuenstliche” Nahstellen bei aneinandergrenzenden Flaechen hat man sowieso in der Karte, da es bei OSM ja aus verschiedenen Gruenden durchaus ueblich ist, Objekte in mehreren Einzelteilen zu erfassen. Und in einem derartigen Fall hat man dann sogar noch die Besonderheit, dass sogar eine Software ganz einfach erkennen koennte, mit was fuer einer Struktur sie es zu tun hat.

=> Diese Art der Erfassung ist zwar unueblich aber im Gegensatz zu manchem Relationsmurks in keiner Weise schaedlich.

Von mir duerften sich auch noch aehnliche Objekte in der Datenbank finden lassen, die stammen dann aus der Zeit, als auch die multipolygon-Relationen noch alles andere als etabliert waren.

Gruss
Torsten

Das wovon du hier redest, sieht nach dem Rendern wie eine Fläche aus, ist aber keine einzelne geschlossene Fläche. Da liegt der kleine, aber feine Unterschied.

Der Unterschied ist in OSM ganz klar definiert: Eine Fläche ist ein way, dessen Start- und Endpunkt identisch sind.
Alle Versuche z.B. mit st_area(geom) die Fläche im m² zu berechnen oder mit st_centroid(geom) den Mittelpunkt dieser “Fläche” zu bestimmen, müssen scheitern, weil es sich hier um mehrere gleiche Flächen handelt, die nun mal direkt aneinander liegen.

Das ist ein historisches Relikt, das “damals” entstanden ist, weil man es nicht besser wusste. Selbst ich hab das vor einem Jahr aus reiner Unwissenheit so gemacht.

Ich bitte um reale Beispiele: Eine Funktion, die den gemeinsamen Mittelpunkt beliebig vieler gleich getaggter aneinander liegenden Flächen (die eigentlich eine gemeinsame Fläche beschreiben) würde mich schon überraschen erfreuen.

wenn du damit “sieht doch auf den Karten prima aus” meinst, könnte ich dir ja noch zustimmen, aber ommmmm…

Gruss
Walter

Nein, schaue es dir doch genau an: Das Polygon beschreibt korrekt eine einzelne, zusammenhaengende Flaeche. Es gilt lediglich nicht, dass das Polygon gleichzeitig den Rand der Flaeche markiert.

Nein, es gibt auch Linien die keine Flaechen darstellen, bei denen aber der Start- und der Endpunkt indentisch sind (z.B. Kreisverkehr). Die Unterscheidunmg findet bei OSM z.Z. lediglich ueber die Tags statt, und da gibt es halt leider einiges an Interpretationspielraum.

s.o. bzw. s.u.

Das ist auch heute noch gute Praxis, z.B. um zu verhindern, dass einzelne Kartenobjekte zu unhandlich/zu gross werden.

Du hast anscheinend die hier vorliegende Struktur nicht richtig erfasst.

Stell dir mal vor, du hast eine C-foermige Flaeche mit weiter Oeffnung. Wenn du eine Funktion hast, die fuer diese Flaeche den Flaecheninhalt oder den Mittelpunkt berechnen kann, dann sollte diese Funktion auch noch funktionieren, wenn die Oeffnung schmaler wird. Im Grenzfall wird die Oeffnung dann so schmal, dass sie gar nicht mehr offen ist, wie in diesem Fall. Das aendert dann auch nichts am Funktionieren deiner Funktion.

Gruss
Torsten

jojo, jetzt hab ich es auch wieder gesehen: das “C”, um ein MP -übrigens der allereinfachsten Art- zu vermeiden.
outer/inner/fertig - selbst Anfängern zuzumuten.

Hier mal zwei Beispiele, wozu das führt:

http://wnordmann.homeunix.com/images/stories/osm/forum/split_meadow1.png

und

http://wnordmann.homeunix.com/images/stories/osm/forum/split_meadow2.png

Darauf bezogen sich meine vorigen Aussagen.

Aber dennoch bleibe ich dabei: Linien zu zeichnen, wo nichts ist, halte ich für unsinnig (= macht keinen Sinn).
Das wurde/wird nur gemacht, um etwas Bestimmtes zu erreichen (hier den Renderer zu überlisten) aber nicht um die Realität in OSM einzutragen.
Da ist nichts, was die beiden Enden des C’s miteinander “verbindet”.

OK, dann berechne mir mal den korrekten Umfang der Fläche, damit ich den benötigten Zaun bestellen kann; bei dieser Methode dürfte es etwas teurer werden.

Gruss
Walter

@de_muur und wambacher
Bevor noch Blut fließt…
Die Beispiele von Wambacher sind m.E. extrem und vermeidbar, jedoch…
…Wälder teilen wir dich auch mit “künstlichen Nahtstellen” auf, um die überhaupt noch einigermaßen handhaben zu können, und da wird das dann auch nix mehr mit Zaun bestellen

ok, vertragen wir uns wieder

bei den Wäldern muss ich auch gelegendlich passen; die sind wirklich zu gross.

Von diesen “extremen” Stellen gibt es in einer bestimmten Ecke noch dutzende - aber ich will nicht wieder mobben.
Das richtig verrückte bei denen ist: Aussen rum ist das ein prima MP (forest mit outer/inner) und dann fängt da drin auf einmal dieses “Patchworking” an.

Gruss
Walter

Wenn man sich bei OSM doch immer so guetlich einigen koennte, denn aufgrund der inzwischen breiten Akzeptanz von (einfachen) Multipolygon-Relationen finde ich solches Tagging heute ja auch nicht passend.

Das soll jetzt kein Nachtreten sein, sondern nur so am Rande bemerkt:

So aufwendig ist das nicht, da man hier ja schon (softwaremaessig) merken kann, dass einige der Knoten mehrfach im Polygon auftauchen. Man kann also feststellen, welche Strecken doppelt vorkommen und diese dann bei der Zaunbestellung auslassen. Das erheoht natuerlich ein bisschen den Aufwand, aber dramatisch ist das nicht.

Viel verruecktere Sachen kann man uebrigens anstellen, wenn man Ueberkreuzungen der Randkannten einbaut, quasi ein Rechteck so verdreht, dass da eine Sanduhr draus wird. Da wird es dann schon schwierig softwaremaessig ueberhaupt zu erkennen, auf welcher Seite des Polygonzugs nun Innen sein soll.

Gruss
Torsten

Das sollte aber nicht sein, weswegen derartige “self intersection” auch als Error ausgeworfen wird:
http://wiki.openstreetmap.org/wiki/DE:Fixing_OSMI_self_intersection

Dort steht auch was zu den “nach innen geführten” Flächenumrandungen (c-shape)