Multipolgonwahnsinn - oder: Durchblick war gestern!

mdk · 2012-06-15 15:19:43

Weide wrote:

mdk wrote:
Ich habe bei Multipolygonen auch häufig das Problem, dass ich nicht so recht erkenne, was zur Fläche gehört und was nicht. Dazu muss ich immer alle beteiligten MPs komplett herunterladen, sonst zeigt mir JOSM nur ein abstraktes Gemälde ohne Semantik an.
Das verstehe ich nicht. Wenn ich ein (nicht kaputtes) Multipolygon habe, dann ist die Fläche doch klar. Andere Multipolygone braucht man da nie; man braucht ja nicht einmal die Tags der Member.
Weide

Also noch mal ganz klar: Bei intakten, fehlerfreien Multipolygonen reicht es tatsächlich, dass man nur die betroffe Relation vollständig herunterlädt (der Zusatzschritt ist immer notwendig!). Aber ich repariere regelmässig Multipolygone. Das heisst ich finde auf OSMI rotes Zeugs, lade mir die Gegend runter und muss versuchen zu verstehen, was der Mapper dort machen wollte. Dazu muss ich mir einen Überblick verschafften. Und da nur dann klar ist, was bei einem MP innen und was aussen ist, wenn die outer vollständig geladen sind, muss ich zuerst das fehlerhafte und in der Regel auch an den Fehler angrenzende MPs herunterladen. Um zu kontrollieren, das ich durch meine Edits nicht selber MPs zerstöre, muss ich auch alle potentiell betroffenen MPs komplett herunterladen und kontrollieren.

Es gibt offenkundig bei MPs verschiedene Arten eine Situation abzubilden. Solange du nur mit Multipolygonen zu tun hast, die du selber erzeugt hast, ist dir das Konzept klar und übersichtlich. Ausser du bist Masochist und magst es dir selber Probleme zu bereiten. Aber als "Fremder" in solch einer Region muss ich zuerst verstehen, welcher "Schule" er angehört, um Fehler zu beseitigen.

Willi2006 · 2012-06-15 17:11:29

mdk wrote:

Folgendes muss einem bewust sein: Wenn sich Flächen überlagern, ist die Bedeutug (Semantik) nicht automatisch klar. Es gibt eindeutig korrekte Überlappungen (z.B. building=yes und landuse=residential) und eindeutig falsche (z.B. landuse=farmland und landuse=forrest). Und dann gibt es Überlappungen, die nicht so klar sind (gehört ein Park oder Spielplatz zum Wohngebiet oder nicht?) Jede Applikation muss selber damit zurecht kommen, wie es überlappungen handhabt. In Mapnik kann eine Fläche eine andere "verdecken" (z.B. landuse=forrest/meadow/farmland) oder wird mit Hilfe von Transparenz gleichzeitig dargestellt (z.B. natural=wetland). Wenn Flächen "verdrängt" werden, braucht es dafür Regeln.
Die "Reihenfolge" oder "Priorität" der Flächen ist aber relativ "willkürlich" und hängt vom Typ, der Grösse, der Lage ("ist komplett innerhalb von") oder anderen Faktoren ab. Ferner hat jede Applikation ihre eigene Logik, welche Fläche welche andere verdrängt. Und schliesslich ändert sich diese Priorisierung teilweise auch mit der Zeit. Z.B. hat früher in Mapnik ein leisure=sport_center höhere Priorität als eine leiusre=pitch, heute verdeckt das Sportzentrum "nur" noch Parkplätze auf dem Gelände. Daher wären die alten MPs, die Tennisplätze aus dem Tennisklub ausschneiden ("mapping für den Renderer"), heute überflüssig.

Beruhen diese Aussagen auf fundiertem Wissen wie Renderer arbeiten oder ist dies Spekulation und Wunschdenken?

Renderer folgen immer noch sehr einfachen Regeln. Welches Symbol oder welche Fläche ein anderes oder eine andere bei Überlappung überdeckt ergibt sich schlicht aus der Zeichenreihenfolge des Renderers. Eine Überlappung oder ein "liegt in" erkennt er nicht. Und schon gar nicht überlegt er ob ein Spielplatz zum Wohngebiet gehört oder nicht.

So werden Gebäude nach den Flächen gezeichnet und überdecken diese dann. Sie stehen ja üblicherweise auf der Erdoberfläche. Bei Gebäuden auf Flächen bedarf es keines Multipolygons. Unterirdische Gebäude werden mit dem Merkmal layer markiert.

Die verschiedenen Flächen sind Teile der Erdoberfläche und eigentlich gleichberechtigt. Bei Überlappung überdeckt jedoch eine undurchsichtige, später gezeichnete Fläche die vor ihr gezeichnete. Das Ergebnis ist somit dem "Zufall", nämlich den Regeln des Renderers, die sich jederzeit ändern können, überlassen. Wird zum Beispiel Wasser (natural=water) nach Wald (landuse=forest) gezeichnet, so wird der See im Wald wie erwartet dargestellt, der Wald im See jedoch nicht.
Mit Multipolygonen kann der Zufall ausgeschaltet werden. Es kann eindeutig festgelegt werden, was zu zeichnen ist. Sowohl der See im Wald als auch der Wald im See werden wie erwartet dargestellt.

Dies wurde bereits vor einiger Zeit in diesem Beitrag klargestellt.

Wer sich aus erster Quelle informieren will, der kann für Mapnik die Wiki-Seite Symbology Support und für Maperitive die Handbuchseite Map Layering lesen.

Weide · 2012-06-15 19:10:27

mdk wrote:

Also noch mal ganz klar:...

Jetzt verstehe ich Deine Aussage.

Ich mache sowas auch und kann ich mich dem nur voll und ganz anschließen.

Weide

alter Streuner · 2012-06-15 20:07:32

Heureka!

Könnt ihr mal bitte mein angehängtes test.osm überprüfen ob das technisch OK ist?

Ich glaube manches scheinbare Problem kann man viel einfacher lösen ohne Multipolygone zu benutzen oder Wege zu zerbrechen.

<?xml version="1.0"?>
<osm generator="Merkaartor 0.17" version="0.6">
  <node version="0" lon="10.8087386" lat="49.3487867" timestamp="2012-06-15T19:42:04Z" user="" id="-1" actor="0" dirtylevel="1"/>
  <way version="0" timestamp="2012-06-15T19:42:04Z" user="" id="-2" actor="0" dirtylevel="13">
    <nd ref="-1"/>
    <nd ref="-3"/>
    <nd ref="-5"/>
    <nd ref="-8"/>
    <nd ref="-12"/>
    <nd ref="-17"/>
    <nd ref="-23"/>
    <tag k="highway" v="track"/>
    <tag k="tracktype" v="grade1"/>
  </way>
  <node version="0" lon="10.8083341" lat="49.3472620" timestamp="2012-06-15T19:42:04Z" user="" id="-3" actor="0" dirtylevel="2"/>
  <node version="0" lon="10.8083052" lat="49.3459444" timestamp="2012-06-15T19:42:06Z" user="" id="-5" actor="0" dirtylevel="1"/>
  <node version="0" lon="10.8097209" lat="49.3450409" timestamp="2012-06-15T19:42:07Z" user="" id="-8" actor="0" dirtylevel="2"/>
  <node version="0" lon="10.8090564" lat="49.3438362" timestamp="2012-06-15T19:42:08Z" user="" id="-12" actor="0" dirtylevel="2"/>
  <node version="0" lon="10.8093164" lat="49.3427632" timestamp="2012-06-15T19:42:09Z" user="" id="-17" actor="0" dirtylevel="2"/>
  <node version="0" lon="10.8089986" lat="49.3418031" timestamp="2012-06-15T19:42:10Z" user="" id="-23" actor="0" dirtylevel="1"/>
  <node version="0" lon="10.8053581" lat="49.3428573" timestamp="2012-06-15T19:42:40Z" user="" id="-44" actor="0" dirtylevel="2"/>
  <node version="0" lon="10.8055315" lat="49.3472620" timestamp="2012-06-15T19:42:42Z" user="" id="-49" actor="0" dirtylevel="2"/>
  <way version="0" timestamp="2012-06-15T19:43:11Z" user="" id="-61" actor="0" dirtylevel="10">
    <nd ref="-3"/>
    <nd ref="-62"/>
    <nd ref="-64"/>
    <nd ref="-8"/>
    <nd ref="-3"/>
    <tag k="landuse" v="meadow"/>
  </way>
  <node version="0" lon="10.8113678" lat="49.3475820" timestamp="2012-06-15T19:43:11Z" user="" id="-62" actor="0" dirtylevel="1"/>
  <node version="0" lon="10.8123213" lat="49.3453609" timestamp="2012-06-15T19:43:13Z" user="" id="-64" actor="0" dirtylevel="1"/>
  <way version="0" timestamp="2012-06-15T19:43:28Z" user="" id="-74" actor="0" dirtylevel="10">
    <nd ref="-8"/>
    <nd ref="-64"/>
    <nd ref="-76"/>
    <nd ref="-17"/>
    <nd ref="-12"/>
    <nd ref="-8"/>
    <tag k="landuse" v="acre"/>
  </way>
  <node version="0" lon="10.8125524" lat="49.3427820" timestamp="2012-06-15T19:43:29Z" user="" id="-76" actor="0" dirtylevel="1"/>
  <node version="0" lon="10.8054526" lat="49.3452036" timestamp="2012-06-15T19:48:17Z" user="" id="-106" actor="0" dirtylevel="2"/>
  <way version="0" timestamp="2012-06-15T19:50:03Z" user="" id="-596" actor="0" dirtylevel="23">
    <nd ref="-106"/>
    <nd ref="-617"/>
    <nd ref="-599"/>
    <nd ref="-602"/>
    <nd ref="-606"/>
    <nd ref="-611"/>
    <nd ref="-617"/>
    <nd ref="-106"/>
    <nd ref="-49"/>
    <nd ref="-3"/>
    <nd ref="-8"/>
    <nd ref="-12"/>
    <nd ref="-17"/>
    <nd ref="-44"/>
    <nd ref="-106"/>
    <tag k="landuse" v="forest"/>
  </way>
  <node version="0" lon="10.8065200" lat="49.3451974" timestamp="2012-06-15T19:50:09Z" user="" id="-617" actor="0" dirtylevel="1"/>
  <node version="0" lon="10.8065318" lat="49.3449436" timestamp="2012-06-15T19:50:04Z" user="" id="-599" actor="0" dirtylevel="1"/>
  <node version="0" lon="10.8069804" lat="49.3449512" timestamp="2012-06-15T19:50:05Z" user="" id="-602" actor="0" dirtylevel="1"/>
  <node version="0" lon="10.8069238" lat="49.3454990" timestamp="2012-06-15T19:50:06Z" user="" id="-606" actor="0" dirtylevel="1"/>
  <node version="0" lon="10.8064774" lat="49.3454990" timestamp="2012-06-15T19:50:07Z" user="" id="-611" actor="0" dirtylevel="1"/>
  <way version="0" timestamp="2012-06-15T19:51:25Z" user="" id="-1066" actor="0" dirtylevel="9">
    <nd ref="-617"/>
    <nd ref="-611"/>
    <nd ref="-606"/>
    <nd ref="-602"/>
    <nd ref="-599"/>
    <nd ref="-617"/>
    <tag k="natural" v="water"/>
  </way>
  <bound box="49.341803,10.805358,49.348787,10.812552" origin="http://www.openstreetmap.org/api/0.6"/>
</osm>

SunCobalt · 2012-06-15 20:16:59

alter Streuner wrote:

Heureka!
Könnt ihr mal bitte mein angehängtes test.osm überprüfen ob das technisch OK ist?
Ich glaube manches scheinbare Problem kann man viel einfacher lösen ohne Multipolygone zu benutzen oder Wege zu zerbrechen.

was ist landuse=acre? Formal ist es schon okay aber Du zeichnest Gebietsgrenzen ein, die es gar nicht gibt nur um ein MP zu vermeiden. Und bei vielen Löchern (bspw Lichtungen im Wald) ist die Lösung vermutlich schwieriger als ein MP

fx99 · 2012-06-15 20:30:41

Das Umfahren des Wassers mit identischem Hin- und Rückweg macht keinen Sinn. Wenn es da einen Weg gibt, kamm man die Wald-Grenzen jeweils auf beiden Seiten des Weges setzen.

Basstoelpel · 2012-06-15 23:07:10

Weide wrote:

mdk wrote:
Ich habe bei Multipolygonen auch häufig das Problem, dass ich nicht so recht erkenne, was zur Fläche gehört und was nicht. Dazu muss ich immer alle beteiligten MPs komplett herunterladen, sonst zeigt mir JOSM nur ein abstraktes Gemälde ohne Semantik an.
Das verstehe ich nicht. Wenn ich ein (nicht kaputtes) Multipolygon habe, dann ist die Fläche doch klar. Andere Multipolygone braucht man da nie; man braucht ja nicht einmal die Tags der Member.
Weide

Wenn bei komplizierten MPs einige wenige Elemente defekt sind, dann ist häufig gar nichts mehr klar. MPs sind schlicht unnötig komplizert, was ich jetzt weniger als Argument gegen die Nutzung sondern für ein neues Datenmodell und bessere Editoren verstanden haben möchte. Schon wenn man relativ einfache MPs verbessern will, hat man unnötig viel Arbeit und muß unnötig viel Wissen selbst mitbringen. Wenn man beispielsweise ein MP "aufschneidet" ändern sich die Rollen, das frühere inner ist jetzt outer usw. Es interessiert doch keinen, daß sich die Topologie ändert. Mich eigentlich auch nicht, das sollten alle editoren selbst erledigen.

Mein größtes Problem mit allen Relationen sind übrigens Konflikte beim Hochladen.

Schöne Grüße,

Baßtölpel

pyram · 2012-06-16 02:06:27

erwin6330 wrote:

Dass die Karte bei Euch immer besser wird, liegt wohl daran, dass Ihr einfach gute und fleißige Mapper im Bereich habt, aber auch das hat nach meiner Meinung nichts mit MP´s zu tun.

Nö, dem muss ich heftig widersprechen. Ich vermeide nach wie vor Bereiche, die komplett mit Relationen überversorgt sind, obwohl ich mittlerweile damit umgehen könnte. Als Anfänger hätte ich damals meine Mitarbeit sofort wieder eingestellt, wenn mein Interessengebiet so gemappt gewesen wäre. Leider gibt es mittlerweile gelegentlich "Gastmapper", die nichts weiter tun, als ohne erkennbare Ortskenntnis meine Arbeit in Relationen umzubauen (würg) :-(

Was soll der Unsinn, eine Postleitzahlengrenze, einen highway, zwei landuses und eine Busrelation an einen einzigen way zu hängen. Welcher Anfänger wird hier eine der beiden landuse-Grenzen korrigieren? Und wenn doch - mit wie vielen Fehlern, die wie lange bestehen bleiben?
Btw: "Niemansland" zwischen den landuses kann sehr praktisch und SINNVOLL sein. Der Feldweg zwischen einem Wald und einem Acker gehört nun mal zu keinem von beiden. Weder wird auf dem Weg geackert, noch stehen dort Bäume. Solches "Niemansland" ist bestenfalls nur noch nicht gemappt (z.B. als Wiesenstreifen, wenn es ein tracktype=grade5 ist und es unbedingt sein muss)

Das Kernproblem ist doch, dass die Masse der kleinen Mapper ganz schnell die Lust verliert, wenn's zu kompliziert wird.

SunCobalt · 2012-06-16 08:06:52

pyram wrote:

Leider gibt es mittlerweile gelegentlich "Gastmapper", die nichts weiter tun, als ohne erkennbare Ortskenntnis meine Arbeit in Relationen umzubauen (würg) :-(

Wenn bei mir sowas passiert, würde das reverten. Hast Du mal ein Beispiel?

Taunide · 2012-06-16 09:28:32

SunCobalt wrote:

pyram wrote:
Leider gibt es mittlerweile gelegentlich "Gastmapper", die nichts weiter tun, als ohne erkennbare Ortskenntnis meine Arbeit in Relationen umzubauen (würg) :-(
Wenn bei mir sowas passiert, würde das reverten. Hast Du mal ein Beispiel?

Sowas passiert mehr als nur gelegentlich.

Und Reverts wird ein Anfänger wohl erst recht nicht machen. Oder anderswie um Ärger betteln.

Weide · 2012-06-16 09:33:59

Basstoelpel wrote:

Wenn man beispielsweise ein MP "aufschneidet"...

Was ist das?

Weide

Taunide · 2012-06-16 11:21:57

Mich stören bei landuse MP's am meisten die unlogischen Zuordnungen. Da gibt es in X-Dorf eine Relation 1359862 und gleich daneben eine 1356982 die beides Ackerflächen beschreiben, und die jeweils vollkommen willkürlich zusammengefasste Flächen sind, über Wege und Weiler hinweg.
Wenn ich jetzt in diesem "Acker" eine Wiese, einen Bauernhof oder eine Ansammlung Wohnhäuser als "inner" mappen will, erhalte ich von potlatch, wenn ich in einer Region mit vielen Relationen bin, eine Vorschlagsliste von 200, von denen mindestens 10 mit id's von 13... anfangen. Ich muss also erstmal nachforschen in welcher dieser unsinnigen Relationen ich mich überhaupt befinde, und am besten schreibe ich mir die Nummer auf ein Stück Papier und trag sie direkt ein (als "load relation") anstatt sie in der Liste ewig zu suchen. Am besten hab ich dazu für jede Relation noch ein Browserfenster offen damit ich weiß wo jede anfängt und aufhört. Das ist ziemlich umständlich und macht keinen Spaß.

Da mappe ich lieber in meinem Lieblings-Waldpolygon 70118 im Rheingaugebirge, das breits 600 Elemente hat. Finde ich wieder irgendwo ein unmapptes Bachtal mit Wiese, brauch ich nicht lang forschen zu welcher Relation dieses "inner" wohl gehört und kann es direkt eintragen. Ist mir eigentlich schietegal wie groß diese Relation mal wird. Auch ein Anfänger kann damit umgehen wenn er potlatch benutzt. Aber: dann kommen Leute und schneiden solche Relationen in Teile bloss damit *ihr* Editor sie schneller laden kann, weil sie mal wieder einen Nagel mit dem Vorschlaghammer einkloppen müssen! Die neue Relation hat dann übrigens eine Nummer wie 264971632, die man sich umso "besser" merken kann, je mehr neue Relationen in einem Zeitabschnitt neuproduziert wurden. Aaaaargh!

Last edited by Taunide (2012-06-20 21:45:42)

pyram · 2012-06-16 11:57:16

SunCobalt wrote:

pyram wrote:
Leider gibt es mittlerweile gelegentlich "Gastmapper", die nichts weiter tun, als ohne erkennbare Ortskenntnis meine Arbeit in Relationen umzubauen (würg) :-(
Wenn bei mir sowas passiert, würde das reverten. Hast Du mal ein Beispiel?

Momentan nicht (mehr) :-D
Scheinbar hatte ich es mit einem freundlichen Mapper zu tun (theophrastos). Nach meiner freundlichen Rückfrage hat er es (allerdings kommentarlos) selbst reverted, da seine Änderung nicht fehlerfrei war (daher war es mir aufgefallen).
Selbst Reverten übersteigt meine momentanen Kenntnisse (das kommt schon noch) - mir bliebe nur händisches neu machen.
Aber Dankeschön für das Angebot, mal drüberzuschauen :-)

Wieso gelten eigentlich sich berührende innere Ringe als Fehler? Wenn in einem Waldstück ein Acker und eine Wiese eine gemeinsame Insel bilden, muss man dann noch einen extra Ring um beides (Waldlichtung) machen!? (Gilt im Prinzip ja auch dann, wenn Wiese und Acker als eigene Relation eingetragen sind.)
Solange die "inner" sich nicht überschneiden sollte das doch reichen...

chris66 · 2012-06-16 12:01:36

Überlege doch mal welche Form der Innenteil (das "Loch") des Waldes hat. Die meisten Tools kommen damit zurecht, aber
es ist halt nicht "schön" und entspricht nicht dem GIS Standard.

mdk · 2012-06-16 12:36:38

pyram wrote:

Wieso gelten eigentlich sich berührende innere Ringe als Fehler? Wenn in einem Waldstück ein Acker und eine Wiese eine gemeinsame Insel bilden, muss man dann noch einen extra Ring um beides (Waldlichtung) machen!? (Gilt im Prinzip ja auch dann, wenn Wiese und Acker als eigene Relation eingetragen sind.)
Solange die "inner" sich nicht überschneiden sollte das doch reichen...

Nun, ich vernachlässige mal das Argument, das es im GIS-Bereich ausserhalb von OSM diverse Tools gibt, die damit nicht umgehen können und somit ein Datenaustausch stark behindert wird.

Mein Argument gegen touching inners aus OSM Sicht:
Vor kurzem traf ich in Genf auf eine mehrere Häuserblocks grosse unbebaute Flache komplett innerhalb des landuse=residential. Diese Fläche bestand aus einem Bach mit umgebenden Buschland (natural=scrub), eine Wiese (landuse=grass) oberhalb des Buschlandes und einem Bauernhof (farmyard) und einem Feld (farmland) unterhalb. grass, farmyard und farmland waren als inner des residential gemapped. Das Buschland hatte jedoch der Mapper vergessen. Also gehörte das Buschland gleichzeitig noch zum Wohngebiet, was aber keinen Sinn machte. Da der Renderer aber das Buschland sauber zeichnete, war ja alles "ok".

Wenn man nicht ein Loch ohne Taggs als inner macht und darin dann einfach den Inhalt des Loches mapped, sondern stattdessen den Innenraum detailiert mapped, dann vergisst man leicht eine der Teilflächen als inner zu markieren und ohne es zu merken, erhält diese Teilfläche ZUSàTZLICH die Eigenschaft des outer.

[Edit] Und man macht es nachfolgenden Mappern schwerer, da sie bei neuen Flächen immer prüfen müssen, ob nicht eine der angrenzenden Flächen ein inner eines MPs ist und ob die neue Fläche dann dort ebenfalls ausgestanzt werden muss.

Last edited by mdk (2012-06-16 12:41:40)

pyram · 2012-06-16 22:24:23

OK, akzeptiert.
Es ist also eher ein datentheoretisches Problem. Man sollte es so machen - insbesondere, wenn es den Überblick erleichtert.

Nachdem hier ja das Thema unübersichtliche Datenstrukturen ist: Ich hatte mal das Vergnügen, hier:
http://www.openstreetmap.org/?lat=48.98 … 32&zoom=17
einen Straßennamen zu verbessern. Vor Ärger (der Straßenname steht an unzähligen Objekten), dass in diesem Dorf auch jede "Hundehütte" und jede Straße(!) eine Adresse hat und zudem noch "associatedStreet" verwendet wird, war ich kurz davor, alles völlig neu zu mappen.
EditWar liegt mir aber nicht ;-)

Sollte man nicht doch Zwangsstandards (nur für bestimmte Basiselemente - demokratisch abgestimmt) einführen? Momentan widersprechen sich sogar die Editoren Potlach und JOSM, wenn man einen Rad-/Fußweg mit Beschilderung mappt (highway=cycleway/path). Letzteres wird dann wiederum vom Standardrenderer nicht als Radweg dargestellt...
Vielleicht kann man dann auch den ein oder anderen Glaubenskrieg zwangsbeenden, die Daten sind für eine breitere Schicht einfacher nutzbar und Gelegenheitsmapper tun sich leichter :->

(Sorry, ich weiche vom Thema ab - lag mir aber auf dem Herzen)

Basstoelpel · 2012-06-16 23:00:55

Weide wrote:

Basstoelpel wrote:
Wenn man beispielsweise ein MP "aufschneidet"...
Was ist das?
Weide

Die Fläche so ändern, daß das inner und outer Kontakt zueinander bekommen. Also von ringförmig auf C-förmig ändern.

Baßtölpel

mdk · 2012-06-20 11:59:44

Nachdem OSMI wieder aktualisiert, arbeite ich die aktuellen Fehler in "meiner" Region ab. Hier ein aktueller Schmankerl: http://www.openstreetmap.org/browse/way/25885762
Der Weg ist
* eine Strasse
* Teil der landuse=farmland Relation 1563413 (vermutlich als outer)
* Teil der landuse=forrest Relation 1563411 (vermutlich als outer)
* Teil der landuse=farmland Relation 1563403 (vermutlich als outer)
* Teil der landuse=farmland Relation 1563399 (vermutlich als outer)
* Teil der landuse=grass Relation 1563412 (als outer)

Der Mapper spart sich nicht nur inner/outer Rollen, sondern hat auch sonst irgendwie die Übersicht verloren. Da alle MPs nur outer Mitglieder haben, vermute ich, das der Mapper diesen Weg auch als outer verwenden wollte.

Da aber ein Weg höchstens zu 2 MP von einer Flächenart (in diesem Fall landuse) gehören kann ("links vom Weg" und "rechts vom Weg"). Sind hier 3 Flächenrelationen zu viel.

Ich werde mir die Sache am Wochenende genauer anschauen und dann vermutlich das MP Chaos durch einfache Flächen ersetzen. Ausser einer der Multipolygonisten will sich vorher mit dem Fall beschäftigen

FvGordon · 2012-06-20 22:57:56

mdk wrote:

Nachdem OSMI wieder aktualisiert, arbeite ich die aktuellen Fehler in "meiner" Region ab. Hier ein aktueller Schmankerl: http://www.openstreetmap.org/browse/way/25885762
Der Weg ist
* eine Strasse
* Teil der landuse=farmland Relation 1563413 (vermutlich als outer)
* Teil der landuse=forrest Relation 1563411 (vermutlich als outer)
* Teil der landuse=farmland Relation 1563403 (vermutlich als outer)
* Teil der landuse=farmland Relation 1563399 (vermutlich als outer)
* Teil der landuse=grass Relation 1563412 (als outer)
Der Mapper spart sich nicht nur inner/outer Rollen, sondern hat auch sonst irgendwie die Übersicht verloren. Da alle MPs nur outer Mitglieder haben, vermute ich, das der Mapper diesen Weg auch als outer verwenden wollte.
Da aber ein Weg höchstens zu 2 MP von einer Flächenart (in diesem Fall landuse) gehören kann ("links vom Weg" und "rechts vom Weg"). Sind hier 3 Flächenrelationen zu viel.
Ich werde mir die Sache am Wochenende genauer anschauen und dann vermutlich das MP Chaos durch einfache Flächen ersetzen. Ausser einer der Multipolygonisten will sich vorher mit dem Fall beschäftigen

Hallo mdk,

so schwer war das gar nicht - der als Link angegebene Weg in Deinem Beitrag war nicht geteilt worden und daher Mitglied mehrerer angrenzender Flächen auf seiner ganzen Länge. Ich habe nach dem Teilen des Weges an mehreren Stellen die nicht mehr benötigten Wegstücke aus den Relationen entfernt und die Reihenfolge sortiert. Nun sind die Flächen wieder in Ordnung.

Grüße,
Franz

mdk · 2012-06-22 14:53:29

Hallo FvGordon

Das Beispiel war auch eher dazu gedacht zu zeigen, das ein unerfahrener User in einem mit MPs geammpten Bereich schnell grossen Schaden anrichten kann (ein Weg mergen und schon sind 5 Landflächen verschwunden?)

Etwas weiter südlich wurde versucht ein Kreisel einzufügen. Da die Strassen selber als MP Begrenzungen dienen, ist dort nun der forrest defekt. Auch kein "unlösbares" Problem, aber für den Mapper scheinbar selbst nach 2 Versuchen zu schwer (letzter Changeset Kommentar: "second attemped to fix multipolygon").

Mit den Beispielen geht es mir darum, zu zeigen, wie fragil MPs auf Fehler reagieren - und wie dadurch Neulinge von der Mitarbeit abgehalten werden.

pyram · 2012-06-22 22:23:38

Nachdem es offenbar eine große Mehrheit gibt, die für eine einfache Datenstruktur ist, mache ich mal folgenden Denkanstoß:

Alle, die gerne mit Multipolygonen arbeiten, sollten sich darauf beschränken - soweit möglich - nur gleichartige Elemente zu einem Multipolygongeflecht zu verweben. Damit meine ich beispielsweise, dass aneinandergrenzende(!) landuses gemeinsame outer haben können, aber z. B. highways keine outer von landuse sein können. Letzteres ist nämlich auch logischer Unfug. Der Acker endet eben nicht mitten in der Bundesstraße, beziehungsweise grenzen die Äcker links und rechts davon nicht aneinander!
Hier werden nämlich zwei verschiedene "Typen" miteinander verkreuzt: landuse hat eine räumliche Ausprägung (wie die Realität), highway ist eine logische lineare Verbindung (obwohl die Straße in der Realität auch eine Fläche bildet).

Weiterhin wären die Daten von landuse dann auch hinsichtlich ihrer Fläche auswertbar (vieviel Acker/Verkehrsfläche gibt es im Ort XY...). Obwohl ich andererseits bisher selten hierfür auswertbare (d.h. hinreichend richtige) Gebiete gesehen habe (wenn, dann Katasterimport, da Profis das auseinanderhalten). Viele malen nur, damit alles irgendein landuse mit der "richtigen" Farbe hat :-(
Der teilweise exzessive Gebrauch von park, village_green usw. beweist das bzw. zeigt das diesbezüglich noch unausgereifte Taggingsystem.
Wenn es hier keine vernünftige Lösung gibt, bleibt OSM im Kern "Street"-Map und die Flächen werden "für den Renderer" gemappt...

cepesko · 2012-06-23 20:53:37

KISS bzw. KUSS, (keep it simple stupid!) so steht es in der Wiki zu den Multipolygonen!

Als Neuling bei OSM kann ich Nop und seiner Kritik nur beipflichten und mein erstes Posting wiederholen:

Mein Kontakt mit OSM vor einem halben Jahr erfolgte via Potlatch2. Wäre meine Heimat von Multipolygonen umgeben gewesen, wie sie gleich nördlich von mir auftauchen (63 Members), hätte ich, obwohl PC-affin, kaum etwas verstanden und mir wäre wahrscheinlich die Lust am Einstieg bei OSM vergangen.

Für eingefleischte Informatiker ist Datenredundanz ein Gräuel, aber in der wiki steht - ich denke zurecht - , dass ein Way lieber doppelt gezeichnet werden soll, wenn dadurch eine bessere Übersichtlichkeit/Verständlichkeit erreicht wird.

OSM wird der Erfolg vorallem dann beschert sein, wenn es das aktuellste Geoinformationssystem ist, bei dem alle mitmachen können. Stellt OSM auf eine viel breitere Basis, durch Einfachkeit. Riesen-Multipolygone wirken abschreckend, so sauber sie auch erscheinen.
Jetzt ist die Chance: Immer mehr Normalbürger haben GPS-Handys, Geo-Caching ist trendy, also solltet ihr dieses noch zunehmende Potential doch nutzen !!!!

Und das wichtigste Mittel für den Einstieg vieler ist ein intuitives, browser-basiertes Bearbeitungstool, a la Potlatch.

Es grüßt, cepesko

PS: Mein sehr aktiver Nachbar im Norden (der mit den MPs) hat sich schon über mich als weiteren Mitarbeiter gefreut Eigentlich müsste ich ihn darauf aufmerksam machen, dass sein Umbau zu MPs in der Region vielleicht auch potentielle neue Helfer fernhält, aber Ich trau mich nicht....

free_as_a_bird · 2012-06-24 16:55:42

KISS bzw. KUSS, (keep it simple stupid!) so steht es in der Wiki zu den Multipolygonen!

Man kann es nicht häufig genug wiederholen..

Auch die Use Cases, die hier für die komplexen Fälle angeführt werden, gehen meiner Meinung nach an dem, was die breite Masse mit den OSM-Daten macht/machen will, völlig vorbei:
Mal ehrlich, wer von Euch betreibt denn ein GIS-System, welches bspw. mit überschneidenden Flächen nicht zurecht kommt?

Rbg_Hessen · 2012-06-26 19:28:58

Hallo,
kann sich dieses Multipolygon:
http://keepright.ipax.at/report_map.php … r=33881763

mal jemand anschauen und den Fehler korrigieren ?
Ich würde dann mall die Umrisse nach den Gegebenheit „verbessern“ .
Will aber nicht anfangen wenn schon gleich Fehler drinnen sind.
Dazu habe ich noch zu wenig Multipolygon Erfahrung

Danke Gruß
Hans

MasiMaster · 2012-06-26 19:53:07

Das Problem was hier bei der Ronneburg war ist:
Es existiert ein einzelner Knoten mit einigen Tags + Einige Tags waren in dem 'outer'-Ring der Relation + Einige Tags waren in der Realtion selber.
Lösung: Habe alle Tags in die Realtion übernommen.

Gruß
Masi

P.S.: keepright zeigt neuerdings Knoten und Wege (in der Nähe) mit dem selben Namen als "mögliche Redundanz" an.

Last edited by MasiMaster (2012-06-26 19:57:59)

OpenStreetMap Forum

#151 2012-06-15 15:19:43

Re: Multipolgonwahnsinn - oder: Durchblick war gestern!

#152 2012-06-15 17:11:29

Re: Multipolgonwahnsinn - oder: Durchblick war gestern!

#153 2012-06-15 19:10:27

Re: Multipolgonwahnsinn - oder: Durchblick war gestern!

#154 2012-06-15 20:07:32

Re: Multipolgonwahnsinn - oder: Durchblick war gestern!

#155 2012-06-15 20:16:59

Re: Multipolgonwahnsinn - oder: Durchblick war gestern!

#156 2012-06-15 20:30:41

Re: Multipolgonwahnsinn - oder: Durchblick war gestern!

#157 2012-06-15 23:07:10

Re: Multipolgonwahnsinn - oder: Durchblick war gestern!

#158 2012-06-16 02:06:27

Re: Multipolgonwahnsinn - oder: Durchblick war gestern!

#159 2012-06-16 08:06:52

Re: Multipolgonwahnsinn - oder: Durchblick war gestern!

#160 2012-06-16 09:28:32

Re: Multipolgonwahnsinn - oder: Durchblick war gestern!

#161 2012-06-16 09:33:59

Re: Multipolgonwahnsinn - oder: Durchblick war gestern!

#162 2012-06-16 11:21:57

Re: Multipolgonwahnsinn - oder: Durchblick war gestern!

#163 2012-06-16 11:57:16

Re: Multipolgonwahnsinn - oder: Durchblick war gestern!

#164 2012-06-16 12:01:36

Re: Multipolgonwahnsinn - oder: Durchblick war gestern!

#165 2012-06-16 12:36:38

Re: Multipolgonwahnsinn - oder: Durchblick war gestern!

#166 2012-06-16 22:24:23

Re: Multipolgonwahnsinn - oder: Durchblick war gestern!

#167 2012-06-16 23:00:55

Re: Multipolgonwahnsinn - oder: Durchblick war gestern!

#168 2012-06-20 11:59:44

Re: Multipolgonwahnsinn - oder: Durchblick war gestern!

#169 2012-06-20 22:57:56

Re: Multipolgonwahnsinn - oder: Durchblick war gestern!

#170 2012-06-22 14:53:29

Re: Multipolgonwahnsinn - oder: Durchblick war gestern!

#171 2012-06-22 22:23:38

Re: Multipolgonwahnsinn - oder: Durchblick war gestern!

#172 2012-06-23 20:53:37

Re: Multipolgonwahnsinn - oder: Durchblick war gestern!

#173 2012-06-24 16:55:42

Re: Multipolgonwahnsinn - oder: Durchblick war gestern!

#174 2012-06-26 19:28:58

Re: Multipolgonwahnsinn - oder: Durchblick war gestern!

#175 2012-06-26 19:53:07

Re: Multipolgonwahnsinn - oder: Durchblick war gestern!

Board footer