Will man die touching-inner_rings vermeiden, darf man beim Mappen der beiden landuse diese nicht übereinander zeichnen. Man kann danach dann die nodes in Deckung bringen und die Frage ob diese verbunden werden sollen verneinen (Merkaartor mit Defaulteinstellung). Allerdings meckert dann der OSMI wegen intersection_points.
Man kann jetzt aber die Flächen getrennt verschieben, was davor nicht der Fall war.
Ergo IMHO: Es ist wohl nicht möglich, zwei sich berührende Flächen mit übereinander liegenden Linien zu mappen, ohne daß der OSMI meckert. Kann man wohl nur vermeiden, indem die Flächen vollkommen getrennt gezeichnet werden.
Wir sind aber in der OSM-Welt, und alles Außerirdische kann uns herzlich egal sein.
Je größer ein Projekt, desto wichtiger ist es, Schnittstellen zu definieren und einzuhalten. Die Schnittstelle für erweiterte MP ist in OSM genau definiert, und unsere Aufgabe als Mapper ist es, entsprechend dieser Definition zu mappen. Ob von der anderen Seite die Schnittstellen eingehalten werden, braucht uns nicht zu kümmern - das ist für uns quasi eine Blackbox. Daher der Spruch “wir mappen nicht für die Renderer”.
Da die Diskussion hier wohl keine Einigung bringen wird, verweise ich einfach auf einen anderen thread, in dem ich meine Vorgehensweise geschildert habe: http://forum.openstreetmap.org/viewtopic.php?pid=165657#p165657
Für mich ist das eine einfache Erfassungsart, die OSM-gerecht ist und mit der auch Standards außerhalb unseres Tellerrandes (,über den einige wohl nicht herausschauen wollen,) klarkommen. Sollte irgendein Mapper in dem Loch dann weitere Flächennutzungen erkennen und mappen, muss er sich zudem nicht um die MP-Konstruktion kümmern, wodurch Fehler vermieden werden können.
Für mich überwiegen bei dieser Art des mappens eindeutig die Vorteile.
Du schreibst da: ‘In das Loch werden dann die scrub und meadow als neue Fläche (auch über vorhandene Knoten eingezeichnet ohne Bezug zu dem MP. Somit ist das nix-Loch mit etwas gefüllt, aber touching inner usw. gibt es nicht.’
Touching_inner nicht aber intersection_points, wenn über vorhandene Knoten des Lochrandes (meinst Du wohl?) gezeichnet. Siehe auch mein Posting #21.
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.
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.
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.
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.’
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.
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.
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.
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.
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…
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.
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.
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.
