Multipolygon Hilfe (Inner und Outer Berühren sich in einem Punkt)

TheFive · 2011-06-24T06:00:29.000Z

Hallo,

irgendwie hab ich gerade einen Knoten im Gehirn.

Ich bin ja immer noch bei den Self Intersections (wobei sich südlich von Frankfurt ein Mitstreiter gefunden hat, der hoffentlich bei der Stange bleibt).

Hier

http://tools.geofabrik.de/osmi/?view=geometry&lon=9.19402&lat=50.00111&zoom=18&overlays=self_intersection_ways,self_intersection_points

Ist ein Fall, bei dem ich nicht weiss, wie ich ihn abbilden soll.

[werbung=“Tue Gutes Rede Drüber”]
Meine mit Forum Unterstützung geschriebenen Best Practices helfen auch nicht
http://wiki.openstreetmap.org/wiki/DE:Fixing_OSMI_self_intersection
[/werbung]

Der Schnitt ist eine Klassische 8. Aber in diesem Fall ist eine “verbleibende 0” ein Inner. Also eine Multipolygonlösung.

Aber wenn ich das ohne Geometrieänderung machen (was mein Anspruch ist, wenn ich in anderen Gegenden so “rumfixe”). dann berühren sich
inner und outer in einem Punkt. Der JOSM Validator findet das doof.
Ist der jetzt überpenibel und das wäre korrekt (ich habs nicht hochgeladen), oder gibt es für eine solche Situation keine korrekte Abbildung.

Christoph

hurdygurdyman · 2011-06-24T06:41:48.000Z

Was hältst Du davon , den Bereich um die Schäfer Karls GmbH so aus dem Residential auszuchließen, indem du eine kleine Lücke statt des Kreuzungspunktes auf der Straße lässt?
____
| |
________/ __ |
/
|
So ähnlich wie hier beim Hallengässchen:
http://tools.geofabrik.de/osmi/?view=geometry&lon=9.20303&lat=50.00214&zoom=18&opacity=1.00&overlays=self_intersection_ways,self_intersection_points

Das da:
http://tools.geofabrik.de/osmi/?view=geometry&lon=9.21223&lat=50.00366&zoom=18&opacity=1.00&overlays=self_intersection_ways,self_intersection_points
ist m.E. einfach zu lösen.

P.S.: Deine Best Practices finde ich gut.

de_muur · 2011-06-24T08:46:29.000Z

Ich denke, dass das einer der Faelle ist, wo eine Self Intersection durchaus richtig/sinnvoll ist.

Nur um den Inspector zufrieden zu stellen, wuerde ich da am Wohngebiet nichts aendern, wir mappen ja nicht fuer …

Die 8 kann man gerne Aufspalten, die dabei entstehende 0 sollte dann aber nicht per Multipolygon aus dem Wohngebiet ausgeschnitten werden, da sie ja nicht innerhalb der Flaeche sondern nur an deren Rand liegt. Alles andere macht die Datenstruktur nur unnötig kompliziert.

Gruss
Torsten

hurdygurdyman · 2011-06-24T09:50:36.000Z

de_muur:

…
Die 8 kann man gerne Aufspalten, die dabei entstehende 0 sollte dann aber nicht per Multipolygon aus dem Wohngebiet ausgeschnitten werden, da sie ja nicht innerhalb der Flaeche sondern nur an deren Rand liegt. Alles andere macht die Datenstruktur nur unnötig kompliziert.

Gruss
Torsten

Zu deinen beiden anderen Feststellungen beginne ich keine neue Diskussion.

Mittlerweile ist die Residential geändert und wird von der Autolackiererei Schäfer als industrial überlagert. Auch nicht ok…
Da landuse Überwiegend-Nutzungen abbildet, halte ich es durchaus für zulässig, die Fläche der Autolackiererei nicht explizit als industrial zu taggen. Gewerbliche Flächen kommen immer wieder in Wohngebieten vor. Analog müsste man z.B. jeden alten Bauernhof in Ortskernen auch als farmyard ausschneiden. Zur endgültigen Klärung kann man den Flächennutzungsplan zu Rate ziehen

de_muur · 2011-06-24T10:40:51.000Z

hurdygurdyman:

Mittlerweile ist die Residential geändert und wird von der Autolackiererei Schäfer als industrial überlagert. Auch nicht ok…

Yepp, das sollte so nicht sein.

Da landuse Überwiegend-Nutzungen abbildet, halte ich es durchaus für zulässig, die Fläche der Autolackiererei nicht explizit als industrial zu taggen. Gewerbliche Flächen kommen immer wieder in Wohngebieten vor.

Da stimme ich auch mit dir grundsaetzlich ueber ein, man koennte also das landuse=industrial fuer die Autolackiererei auch einfach loeschen. (Waere das nicht sowieso besser landuse=commercial?)

In diesem Fall spricht aber dagegen, dass schraeg gegenueber ja weitere Gewerbeflaechen liegen. Es ist also nicht ein Thema, ob man dort eine Flaeche explizit als Gewerbeflaeche erfassen will, sondern die Frage ist nur, wie man diese von der Wohnflaeche abgrenzt. Ich halte es hier also fuer die schlechtere Loesung, die Lackiererei dem Wohngebiet zuzuordnen.

Gruss
Torsten

Jayjay01 · 2011-06-24T11:01:51.000Z

hurdygurdyman:

Da landuse Überwiegend-Nutzungen abbildet, halte ich es durchaus für zulässig, die Fläche der Autolackiererei nicht explizit als industrial zu taggen. Gewerbliche Flächen kommen immer wieder in Wohngebieten vor. Analog müsste man z.B. jeden alten Bauernhof in Ortskernen auch als farmyard ausschneiden. Zur endgültigen Klärung kann man den Flächennutzungsplan zu Rate ziehen

dennoch sollte man das meiner meinung nach nicht einfach löschen, was ein anderer (wenn auch falsch) eingetragen hat, denn auf diesem gebiet ist nunmal eher ein landuse = commercial/industrial als ein residential.
und wenn einer anfängt jeden alten bauernhof in ortskernen auszuschneiden, dann soll er das tun, er hat schließlich auch recht damit, er trägt ja nichts falsches ein. es sollte nur eben nicht zwingend so sein, dass ich wegen ner trinkhalle das landuse=residential ausschneiden muss

auch ein flächennutzungsplan macht da keinen sinn, da gemischte gebiete in osm nicht als gemischt sondern als überwiegend getaggt werden.

hurdygurdyman · 2011-06-24T11:42:07.000Z

Jayjay01:

…
auch ein flächennutzungsplan macht da keinen sinn, da gemischte gebiete in osm nicht als gemischt sondern als überwiegend getaggt werden.

Somit bleibt nur die Frage, wo überwiegend anfängt oder aufhört. Aber dazu einen Konsens hier im Forum herzustellen, halte ich für aussichtslos…

TheFive · 2011-06-24T12:10:05.000Z

hurdygurdyman:

Somit bleibt nur die Frage, wo überwiegend anfängt oder aufhört. Aber dazu einen Konsens hier im Forum herzustellen, halte ich für aussichtslos…

Vergiss einen Konsens, was die Detailtiefe angeht (und darum geht es ja) ist OSM im Fluss, die Richtung ist klar. Die Entropie nimmt zu
http://www.phylex.de/data/data.php?entropie
Wobei ich bei diesem Vergleich mit der Zufälligkeit ein Problem habe.

Fakt ist aber das die Detailgenauigkeit in OSM nicht festgeschrieben ist, sondern wächst, und das es in diesem Prozess immer bewahrende und aufbrechende Kräfte gibt.

Der Prozess ist gut, er zeigt das OSM lebt. Wichtig ist nur, das zu jeder Zeit das ganze in sich betrachtet schlüssig ist.

Christoph

TheFive · 2011-06-25T06:05:23.000Z

Der Vollständigkeit halber.

a) Als ihr euch die Ecke angeschaut habt gab es offensichtlich schon eine Änderung von mir. Die war unvollständigt, ich hatte wohl nicht oft genut
rückgängig in JOSM gedrückt.

b) hab mich für Michaels Vorschlag entschieden, ist halt pragmatisch.

Ich fasse meine Ursprüngliche Frage noch mal zusammen (als vom aktuellen Fehler, der jetzt gelöst ist, betrachtetes Abstraktum)

Dürfen sich Inner und Outer in exakt einem Punkt berühren, oder nicht ?

den Outer “Drumherumzeichnen” ist falsch, da der drumherumgezeichnete Outer self intersecting ist.
Ansonsten meckern JOSM.

wambacher · 2011-06-25T06:59:24.000Z

TheFive:

Ich fasse meine Ursprüngliche Frage noch mal zusammen (als vom aktuellen Fehler, der jetzt gelöst ist, betrachtetes Abstraktum)

Dürfen sich Inner und Outer in exakt einem Punkt berühren, oder nicht ?

den Outer “Drumherumzeichnen” ist falsch, da der drumherumgezeichnete Outer self intersecting ist.
Ansonsten meckern JOSM.

Hi,

laut GIS-Definition dürfen sich die Polygone (Ringe), aus denen sich ein Multipolygon zusammensetzt, an PUNKTEN berühren, aber keine gemeinsamen Linen haben.

siehe hier: http://www.slidefinder.net/G/Geoinformation_III_Normen_und_Standards/gisIII.10a_neu/5858109/p2 (auf rechtes Bildchen klicken)

Inwiefern JOSM oder OSM-I trotzdem “motzen”, werd ich mal durch eine kleine Testreihe evaluieren; Problem ist nur, dass OSM-I mal wieder mächtig in der Aktualität hinterherhinkt.
Ich weiss aber, dass ich sich in EINEM Punkt berührende Polygone innerhalb von MP bereits hatte und dass es da keinerlei Probleme gab.

Mfg
Walter
Nachtrag: Josm “motz”, wenn sich ein “inner” und ein “outer” berühren. was osm-i dazu sagt, werde ich irgendwann ja sehen.
Das Interessante ist, dass es inner/outer beim klassischen gis garnicht gibt. Die Anordnung ergibt sich automatisch aus der Beziehung der Ringe zueinander und nicht aus irgendeinem Attribut.

Dennis_B · 2011-06-25T08:05:59.000Z

Ganz einfache Lösung:

Im Real-Live ist die Straße eine Fläche
Gehört die Straße “dazu” oder nicht?

Jetzt hast Du zu 99% keine Überschneidungen mehr. Denn diese entstehen zu 99,9% nur dadurch, daß die Grenze mal auf der Straßenmitte und mal auf einer Straßenseite leigt. In meinem Heimatort hatte ich ähnliches. Als ich die Teerfläche als Fläche gezeichnet habe (Zusätzlich zur Linie), war der Rest auf einmal ganz eindeutig.

TheFive · 2011-06-25T08:14:40.000Z

'Dennis[B:

']

Im Real-Live ist die Straße eine Fläche

Gehört die Straße “dazu” oder nicht?

a) wenn ich fremdmappe, möchte ich die Geometrie nicht überflüssigerweise ändern.

b) Dummerweise gehöre ich zum anderen Lager, Karten Zeichnen ist für mich Abstraktion und zur Abstraktion gehört, das eine Fläche die AN einer Strasse endet, in OSM die gleichen Punkte wie die Strasse nutzt.

hurdygurdyman · 2011-06-25T12:58:08.000Z

TheFive:

…
b) Dummerweise gehöre ich zum anderen Lager, Karten Zeichnen ist für mich Abstraktion und zur Abstraktion gehört, das eine Fläche die AN einer Strasse endet, in OSM die gleichen Punkte wie die Strasse nutzt.

Wir zeichnen doch keine Karten Das machen doch die Renderer Wir füllen eine Datenbank
Trotzdem stimme ich dir 100%ig zu.

chris66 · 2011-06-25T13:45:00.000Z

'Dennis[B:

']Als ich die Teerfläche als Fläche gezeichnet habe (Zusätzlich zur Linie), war der Rest auf einmal ganz eindeutig.

Hoffentlich nach der neuen Methode?

TheFive · 2011-06-25T14:05:25.000Z

chris66:

'Dennis[B:

']… Teerfläche …

Mit beiden beiden voll auf der Leitung steh.

Warum zeichnen die denn auf die Teerflächen die weissen Linien in der Mitte ? Doch noch damit wir wissen wo wir die ways langlegen müssen.

TheFive · 2011-06-25T16:39:01.000Z

wambacher:

Problem ist nur, dass OSM-I mal wieder mächtig in der Aktualität hinterherhinkt.

Yow, hab jetzt auch ein Live Experiment mit OSM-I gemacht. Sozusagen auf OSM-I WV.

Je länger der nicht updatet um so mehr bekomm ich weg geschaft, die Redundanzen “Da war ich schon” steigen, und alle “Fehlerproduzenten” arbeiten inkognito.
Bilde mir trotzdem ein das es stetig weniger wird.

de_muur · 2011-06-25T19:12:12.000Z

TheFive:

den Outer “Drumherumzeichnen” ist falsch, da der drumherumgezeichnete Outer self intersecting ist.
Ansonsten meckern JOSM.

Ja und, nur weil JOSM meckert, muss das ja nicht falsch sein.

Gruss
Torsten

TheFive · 2011-06-25T19:23:56.000Z

de_muur:

TheFive:

den Outer “Drumherumzeichnen” ist falsch, da der drumherumgezeichnete Outer self intersecting ist.
Ansonsten meckern JOSM.

Ja und, nur weil JOSM meckert, muss das ja nicht falsch sein.

Gruss
Torsten

OSM I meckert leider auch. Ich bin im Augenblick in dem Modus, in diesem Punkt die Fehlermeldungen zu akzeptieren (JOSM kann ich ignorieren) Self Intersections von OSMI nicht. Sonst sind wir irgendwann in dem Modus vor lauter Fehlern, die ja egal sind, die wirklichen Probleme nicht mehr zu sehen,
und dann müssen wir nach Walter abholzen, was nach Walter ja wieder zielführend wäre.
Die Motivation für meinen Elan in diesem Punkt hab ich mittlerweile in die Wiki Seite aus dem ersten Post gepackt.

Der Mechanismus: Das fix ich nicht das ist egal, führt bei mir gerade dazu, das ich alle Rollercoaster in Deutschland, die nicht korrekt gemappt sind,
auswendig kenne.

chris66 · 2011-06-28T09:49:37.000Z

Moin,

902400 wird weder in Mapnik noch in Osma richtig angezeigt.

Findet jemand einen Fehler?

http://www.openstreetmap.org/?lat=51.989&lon=6.64958&zoom=17&layers=M

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

Chris

viw · 2011-06-28T09:59:06.000Z

vielleicht liegt es an dem Polygon unten drunter:
ID: 6324992
Ist schließlich auch Wald.