Wir brauchen feste Regeln für die Verwendung von Multipolygonen!

GerdP · 2018-11-15 20:45:43

OT:Wie kann man eigentlich den Buhcstabnedreher in der Überschrift korrigieren?

kreuzschnabel · 2018-11-15 20:57:08

GerdP wrote:

OT:Wie kann man eigentlich den Buhcstabnedreher in der Überschrift korrigieren?

Dsa knan nru dre Thraed-Eröffenr.

--sk

Nakaner · 2018-11-15 21:26:36

kreuzschnabel wrote:

GerdP wrote:
OT:Wie kann man eigentlich den Buhcstabnedreher in der Überschrift korrigieren?
Dsa knan nru dre Thraed-Eröffenr.

Danke für den Hinweis, ich habe es erledgit.

Vielen Dank für eure Beiteiligung bislang. Ich werde mir eure Kommentare mal in Ruhe nochmal durchlesen und prüfen, für welche Teilaussagen zu Multipolygonen die Aussage "Das ist ein wohl recht breiter Konsens im OSM-Forum" richtig ist. Die Mailingliste Talk-de werde ich selbstverständlich nicht außer Acht lassen und auch dort um Kommentare bitten, bevor ich einen Entwurf verbreite.

EDIT: "und auch dort um Kommentare bitten, bevor ich einen Entwurf verbreite" ergänzt.

Last edited by Nakaner (2018-11-15 21:27:33)

miche101 · 2018-11-15 21:51:53

Jo Cassel wrote:

Um einen bekannten Spruch abzuändern:
"Wer Multipolygone sät, wird Inner ernten."

k.A. muss irgendeinen Grund gehabt haben... in 10 Jahren ändert sind ja einiges Änderungssatz war mit 3D die Kirche.. immer wieder schön http://demo.f4map.com/#lat=48.1916560&l … phi=-9.167

streckenkundler · 2018-11-15 22:08:31

AB-inf-x-chg-AB wrote:

Wäre es dann für diesen Fall "Touching inner Rings" auch irgendwie möglich eine Abfrage zu erfinden?

Ich würde ganz stark vermuten, daß das die Möglichkeiten von Overpass leider übersteigt... Für "Touching inner Rings" müsste ausgewertet werden, ob bei den Inner-Rollen innerhalb eines MP's mindestens zwei der aufeinanderfolgenden Stützpunktkoordinaten gleich sind.

Typischerweise ist das aber eine (geometrische!) Topologieregel, die man erst wirklich gut beim Vorhandensein des echten Datentyps Polygon prüfen kann(*)... In Verarbeitungsschritten von OSM zu PostgreSQL kan man das sicher dann machen, allein auf Basis von reinen OSM-Daten dürfte das schwierig werden.

(*) den OSM aber eben noch immer nicht nicht hat, was wiederum begründet, daß OSM für solche Flächen eben diese MP-Konstrukte für Flächen hat...

An der Stelle hinken übrigens auch irgendwelche Vergleiche, welcher Mapper wieviel Relationen angelegt hat... Es gibt in der Zahl angelegter Relationen pro User keine Aussage, wie sich diese auf solche hier besprochenen (durchaus notwendigen) Flächenkonstrukte beziehen, oder auf z.B. (linienhaften) Routenrelationenen, ect. (=andere in OSM verwendete Relationstypen) verteilt. Es ist zunächst nur eine stupide, nichtssagende Zahl...

Sven

Pfad-Finder · 2018-11-15 22:28:52

Mit dem Marktschwaben-Residential kann ich pragmatisch betrachtet leben. Es ist flächenmäßig nicht bildschirmsprengend, es gibt nur ein Outer, und ob man eine Secondary durch eine Wohnbebauung als Unterbrechung desselben ansieht, ist Geschmackssache. Bei einer Autobahn sähe ich auch eine "Trennwirkung", aber bis hin zur Bundesstraße (nicht: Kraftfahrstraße) halte ich es für vertretbar, ein residential drüberzuziehen. Trennen würde ich dann nur, wenn a) die Ortsteile beiderseits der Straße zum Beispiel eigene Namen haben oder b) ein Gesamtresidential bildschirmsprengend groß wäre.

Ortrand https://www.openstreetmap.org/#map=16/51.3704/13.7599 und Kraußwitz ist so ein ganz klarer Fall - an der Bebauung beiderseits von Grenzstraße/Grenzweg ist kein Unterschied zu erkennen, aber im Norden ist Ortrand in Brandenburg und im Süden Kraußwitz in Sachsen.

Last edited by Pfad-Finder (2018-11-15 22:29:18)

miche101 · 2018-11-15 22:52:42

Pfad-Finder wrote:

ob man eine Secondary durch eine Wohnbebauung als Unterbrechung desselben ansieht, ist Geschmackssache

Naja du schreibst ja schon selbst "Trennwirkung"... wenn man hier auf die Sprache achte dann sagt man ja auch man fährt durch eine Ortsschaft und nicht links und rechts liegt die Ortsschaft... oder man fährt durch den Wald.. und im Wald ist ein See usw. usw. Trennt man das kann man diesen Bezug nicht mehr leicht herstellen bzw. nur schwer.. also kann mit viel mühe auch der Schuss auch nach hinten gehen..

So wie hier... fahr ich da durch oder liegt das links und rechts.. maxspeed=50 könnte da helfen.. https://www.openstreetmap.org/relation/6292132 . Außerdem die Linien neben der Straße finde ich sehr störend beim mappen.. was ich auch gut und gern auch auflöse wenn ich dort was mappe..

mfg Miche

slhh · 2018-11-16 00:23:39

wyo wrote:

slhh wrote:
Wenn man in iD einen geschlossenen Ring, der anhand seiner Tags als Fläche erkannt wird, und einen seiner Nodes selektiert hat, pasiiert meines Wissens folgendes:
Jetzt muss ich da mal nachfragen: Schon beim Selektieren, wird aus einer Fläche ein MP?

Nein. Da habe ich miss missverständlich ausgedrückt. Ich war wohl implizit davon ausgegangen, dass wir über die Split/Teilen-Operation (Scherensymbol) sprechen. Habe es oben editiert.

wyo wrote:

IMHO nicht mal ein Trennen sollte einen Weg resp eine Fläche teilen, das sollte zwingend nur beim Aufschneiden passieren.

Trennen teilt weder Weg noch Fläche.
Teilen (Scherensymbol) teilt den Weg, aber nicht die Fläche, da das Multipolygon erstellt wird.
Ein ein wirkliches Teilen der Fläche, wird in iD bisher nicht direkt unterstützt.

wyo wrote:

slhh wrote:
Das ist schon lange vorhanden. Leider ist eine praktikable Funktion zum Teilen von Flächen sehr schwierig in iD umzusetzen.
Frage: Wenn eine Fläche (z.B ein Fluss) mit einer Brücke (Weg) überquert wird, ist doch ein Teilen der Fläche gar nicht nötig, oder? Das gleiche gilt doch auch für eine Landuse-Fläche, die von einer Strasse gequert wird. Kannst du mal ein Beispiel sagen, wo der ID eine Fläche teilt, obwohl er das nicht müsste?

iD teilt keine Flächen. Was schon lange vorhanden ist, ist das Ticket auf Github.

bison166 · 2018-11-16 11:46:19

Moin......Im Zuge einer Bearbeitung in diesem Gebiet, bin auf diese Relation gestossen.
Macht die überhaupt Sinn ?

https://www.openstreetmap.org/relation/ … 558/8.4842

dx125 · 2018-11-16 12:19:03

Dies könnte man aufteilen entlang der durch das Multipolygon verlaufenden Strassen, Bahntrasse und was sich sonst noch anbietet, natürlich ohne Verkleben, sondern parallel. So ein Multipolygon sollte man in der vorliegenden Form nicht neu anlegen, das kann man kleinteiliger gestalten, und die (meisten) MP-inner sind als normale Relationen möglich, das kann man mit JOSM gut umbauen, falls gewünscht, bin ich behilflich.

bison166 · 2018-11-16 15:05:54

dx125 wrote:

Dies könnte man aufteilen entlang der durch das Multipolygon verlaufenden Strassen, Bahntrasse und was sich sonst noch anbietet, natürlich ohne Verkleben, sondern parallel. So ein Multipolygon sollte man in der vorliegenden Form nicht neu anlegen, das kann man kleinteiliger gestalten, und die (meisten) MP-inner sind als normale Relationen möglich, das kann man mit JOSM gut umbauen, falls gewünscht, bin ich behilflich.

Ich habe mir das in JOSM angesehen.
sehe ich das falsch, wenn ich sage das Ding ist total kaputt ?
nicht geschlossen etc.
Ich mache da nichts dran.

dx125 · 2018-11-16 15:30:06

MPs, deren Aussenring nicht geschlossen war, habe ich hin und wieder schon repariert. Wenn man vor hat, das Monster-MP ganz aufzulösen und durch kleinere Einheiten zu ersetzen, löst man das beschädigte MP besser auf und gliedert die frei gewordene Fläche neu. Ich schau es mir heute abend an, habe gerade kein JOSM.

glglgl · 2018-11-16 16:07:03

bison166 wrote:

Ich habe mir das in JOSM angesehen.
sehe ich das falsch, wenn ich sage das Ding ist total kaputt ?
nicht geschlossen etc.
Ich mache da nichts dran.

Ich sehe da keine Fehler. Zwei Member mit Outer, die miteinander verbunden sind, der Rest sind inner, mit denen aus der Wiese ausgestanzt wird.

dx125 · 2018-11-16 16:29:18

glglgl wrote:

Ich sehe da keine Fehler. Zwei Member mit Outer, die miteinander verbunden sind, der Rest sind inner, mit denen aus der Wiese ausgestanzt wird.

Nach Sichtung in JOSM ist das so.

Meine Ansicht zu diesem speziellen MP: zu groß, zu schlecht bearbeitbar. Es müssten jetzt eigentlich noch mehr Flächen, die bereits gemappt sind (und weitere die noch zu mappen wären, da nicht "Wiese") als inner zum Wiesen-MP hinzu, dann wird es noch unübersichtlicher. In meiner Region würde ich so etwas zerlegen in übersichtlichere kleinere Einheiten. Spätestens an der nächsten größeren Straße, Bahntrasse, Kanal hat das MP aufzuhören

Last edited by dx125 (2018-11-16 16:30:07)

Pfad-Finder · 2018-11-16 18:18:18

Die Diskussion hier belegt, dass das MP nicht ohne weiteres wartbar ist --> Zerlegen!

dx125 · 2018-11-16 18:43:00

Ich fange jetzt mit dem Zerlegen an und bitte alle Anderen, dieses MP und alles was innerhalb ist, bis auf Weiteres nicht anzufassen,
damit man sich nicht ins Gehege kommt Wird sicher nicht perfekt, aber besser als der Ist-Zustand.

dx125 · 2018-11-16 21:44:05

Mit der Abwicklung dieses MPs bin ich jetzt durch: es ist weg!
So was braucht niemand. Dort nicht und Anderswo meist auch nicht.
https://nrenner.github.io/achavi/?changeset=64581915
Es hatte etwas über 20 Elemente und war damit von der Größe her noch "im Mittelfeld", z.B. links nebenan liegt Eines mit 69 Elementen...

GerdP · 2018-11-16 22:13:12

Langweilig ;-)
Versuch mal die natural=wood MP in Japan zu verbessern, so eines wie dieses gibt es dort überall:
https://www.openstreetmap.org/relation/1330990
Knapp 600 Wege, keiner davon auch nur annähernd in der richtigen Position. Wenn ich den Import-Müll sehe, denke ich immer, in D ist es ja noch recht harmlos.

Chrysopras · 2018-11-17 21:54:43

Besser spät als nie:

Nakaner wrote:

TL;DR Ich denke, dass es an der Zeit ist, dass wir als deutsche Community Regeln einführen, die – das meine ich wirklich so – die übertriebene Nutzung von Multipolygonen für unerwünscht erklären.

+1.

Ryzen · 2018-11-18 00:58:49

Während ihr die Multipolygone aufdröselt, klebt gerade ein Südkoreaner alle Wälder in seinem Land zusammen: maphunter36 - bislang hat er nicht auf Ansprache reagiert.

aixbrick · 2018-11-18 10:43:21

miche101 wrote:

Nakaner wrote:
Die Fläche hat innere Ringe, also kann man sie in ihrem aktuellen Zustand nicht als geschlossenen Way mappen.
Ja macht Sinn.. da braucht man eh eine Relation..
Also Relationen mit inner rausfiltern
http://overpass-turbo.eu/s/DEb

Ich habe mal bei der Abfrage in Zeile 11 das "> 1" durch ">= 1" ersetzt. Damit werden auch die MP gefunden, die nur einen outer haben, also eine ganz normale Fläche sind. Wäre das OK, oder handle ich mir damit Probleme ein (z.B. false-positives, d.h. es werden MP angezeigt, die tatsächlich so korrekt gemappt sind)?

GerdP · 2018-11-18 10:57:43

Jetzt muss ich mal blöd nachfragen: Ist es jetzt angesagt, auch vollkommen korrekte MP zu entsorgen, nur weil sie nicht nötig sind? In meiner Heimat haben andere Mapper so ziemlich alle Flächen als MP erfaßt. Ich fasse die eigentlich nur an, wenn ich die Bedeutung ändern will, sprich, wenn etwas falsch oder nicht mehr aktuell ist. Kann ich aber erst machen, wenn neue, bessere Luftbilder da sind.

streckenkundler · 2018-11-18 10:58:17

aixbrick wrote:

Wäre das OK, oder handle ich mir damit Probleme ein (z.B. false-positives, d.h. es werden MP angezeigt, die tatsächlich so korrekt gemappt sind)?

In meinen Augen Ok...

MP's mit nur einem Outer und keinem inner können durch simple Flächen ersetzt werden oder wenn der Outer-Ring nicht geschlossen ist, es eh ein Ringfehler...

Sven

geri-oc · 2018-11-18 11:10:25

GerdP wrote:

Jetzt muss ich mal blöd nachfragen: Ist es jetzt angesagt, auch vollkommen korrekte MP zu entsorgen, nur weil sie nicht nötig sind? In meiner Heimat haben andere Mapper so ziemlich alle Flächen als MP erfaßt. Ich fasse die eigentlich nur an, wenn ich die Bedeutung ändern will, sprich, wenn etwas falsch oder nicht mehr aktuell ist. Kann ich aber erst machen, wenn neue, bessere Luftbilder da sind.

Frage doch per CS oder PN die Mapper ob er mal hier ins Forum schauen kann. Dann kann er auch seinen Standpunkt (vielleicht vor Jahren) darlegen. Oder er stimmt dem sogar zu.

Nakaner · 2018-11-18 11:14:24

GerdP wrote:

Jetzt muss ich mal blöd nachfragen: Ist es jetzt angesagt, auch vollkommen korrekte MP zu entsorgen, nur weil sie nicht nötig sind? In meiner Heimat haben andere Mapper so ziemlich alle Flächen als MP erfaßt. Ich fasse die eigentlich nur an, wenn ich die Bedeutung ändern will, sprich, wenn etwas falsch oder nicht mehr aktuell ist. Kann ich aber erst machen, wenn neue, bessere Luftbilder da sind.

Meine Meinung und Absicht: Nur Ändern des Änderns wegen halte ich für nicht richtig. Da kann man seine Zeit sinnvoller investieren. Wenn jedoch bei der Zerlegung der Multipolygone gleichzeitig das in OSM Erfasste mit neueren Luftbildern abgeglichen wird und es auch zu inhaltlichen Verbesserungen kommt, ist es in Ordnung.

Wenn man Multipolygonfehler repariert, weil ein Mapper eines zerschossen hat, und sich in einem Multipolygon-Teppich wiederfindet, kann man aber schon das betreffende Multipolygon und seine Nachbarn zerlegen. Es sollte einen Anlass für das Zerlegen geben.

Announcement

#76 2018-11-15 20:45:43

Re: Wir brauchen feste Regeln für die Verwendung von Multipolygonen!

#77 2018-11-15 20:57:08

Re: Wir brauchen feste Regeln für die Verwendung von Multipolygonen!

#78 2018-11-15 21:26:36

Re: Wir brauchen feste Regeln für die Verwendung von Multipolygonen!

#79 2018-11-15 21:51:53

Re: Wir brauchen feste Regeln für die Verwendung von Multipolygonen!

#80 2018-11-15 22:08:31

Re: Wir brauchen feste Regeln für die Verwendung von Multipolygonen!

#81 2018-11-15 22:28:52

Re: Wir brauchen feste Regeln für die Verwendung von Multipolygonen!

#82 2018-11-15 22:52:42

Re: Wir brauchen feste Regeln für die Verwendung von Multipolygonen!

#83 2018-11-16 00:23:39

Re: Wir brauchen feste Regeln für die Verwendung von Multipolygonen!

#84 2018-11-16 11:46:19

Re: Wir brauchen feste Regeln für die Verwendung von Multipolygonen!

#85 2018-11-16 12:19:03

Re: Wir brauchen feste Regeln für die Verwendung von Multipolygonen!

#86 2018-11-16 15:05:54

Re: Wir brauchen feste Regeln für die Verwendung von Multipolygonen!

#87 2018-11-16 15:30:06

Re: Wir brauchen feste Regeln für die Verwendung von Multipolygonen!

#88 2018-11-16 16:07:03

Re: Wir brauchen feste Regeln für die Verwendung von Multipolygonen!

#89 2018-11-16 16:29:18

Re: Wir brauchen feste Regeln für die Verwendung von Multipolygonen!

#90 2018-11-16 18:18:18

Re: Wir brauchen feste Regeln für die Verwendung von Multipolygonen!

#91 2018-11-16 18:43:00

Re: Wir brauchen feste Regeln für die Verwendung von Multipolygonen!

#92 2018-11-16 21:44:05

Re: Wir brauchen feste Regeln für die Verwendung von Multipolygonen!

#93 2018-11-16 22:13:12

Re: Wir brauchen feste Regeln für die Verwendung von Multipolygonen!

#94 2018-11-17 21:54:43

Re: Wir brauchen feste Regeln für die Verwendung von Multipolygonen!

#95 2018-11-18 00:58:49

Re: Wir brauchen feste Regeln für die Verwendung von Multipolygonen!

#96 2018-11-18 10:43:21

Re: Wir brauchen feste Regeln für die Verwendung von Multipolygonen!

#97 2018-11-18 10:57:43

Re: Wir brauchen feste Regeln für die Verwendung von Multipolygonen!

#98 2018-11-18 10:58:17

Re: Wir brauchen feste Regeln für die Verwendung von Multipolygonen!

#99 2018-11-18 11:10:25

Re: Wir brauchen feste Regeln für die Verwendung von Multipolygonen!

#100 2018-11-18 11:14:24

Re: Wir brauchen feste Regeln für die Verwendung von Multipolygonen!

Board footer