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

Rogehm · 2018-12-28 18:51:17

Leute, jetzt machen wir zig Baustellen auf und überall steht etwas wichtiges oder weniger wichtiges oder nur Empfehlungen oder eine Anleitung...
Alleine dieser Thread reicht schon, damit 50% der deutschen Mapper wissen, worum es geht.
Und ich denke, die erfahrenen Mapper sind einer solchen "Belehrung" mit diesem ganzen Diskussionsgerede irgendwie müde, weil sie es ja sowieso schon längst machen oder in einigen Fällen vielleicht auch, weil sie sich nicht belehren lassen möchten. Wen wollt ihr eigentlich erreichen?
Mal abgesehen davon, das ihr die beiden deutschsprachigen Länder A/CH mal außen vorgelassen habt, was ich als WN-Redakteur nun überhaupt nicht gut finde, liegt doch eigentlich das Ziel dieser Initiative der Information an Anfänger (Erg.: siehe auch aktueller Eintrag im A-Forum) und Nichtnutzer vom JOSM Editor. Oder?
Jetzt gibt es mehrere Anfänger-Tutorials. Ich möchte ganz besonders das von kreuzschnabel hervorheben, sehr schön als PDF strukturiert aufgebaut. Jetzt hat Frederik noch was Nettes zusammengestellt.
Kann man dies nicht irgendwie alles verlinken?
Auch das jetzige Proposal, wenn es mal etwas klarer dargestellt ist, und zwar wirklich als Richtlinie, worauf sich die "deutschsprachige" OSM Community geeinigt hat, gehört in solche Anfänger Seiten, zumindest verlinkt, die dann hoffentlich auch gefunden wird, wenn man "OSM für Anfänger" googelt. Der Stellenwert dieses Proposals sehe ich nicht höher als gute WIKI Vorlagen, die mal vor 8 Jahren erstellt wurden und noch immer gelten sollen, wie dieses hier, was dann an 2. Stelle steht in der genannten Suche. Erg.: Es wäre fast schon sinnvoller gewesen, dieses Tutorial auf den Stand der Zeit zu bringen...

Last edited by Rogehm (2018-12-28 19:18:21)

miche101 · 2018-12-29 13:21:42

Rogehm wrote:

"OSM für Anfänger"

Es wird hier immer der Anfänger betont... es geht auch um die erfahrenen Mapper.

Man soll einfach keine Monster bauen nur weil man es kann und gut findet... weil geht eins dieses Monster mal kaputt oder es verändert sich was. Dann ist es nicht schön diese Monster zu ändern bzw. zu reparieren. Beim erstellen dieser ist ja alles noch gut und schön und leicht, aber später...

z.B. so was:
https://www.openstreetmap.org/relation/178160

..warum muss das alles in einem MP sein? Muss das sein? Hätte man da nicht mehrere machen können

Der Punkt 5 macht das deutlich, wie unschön das ist.. im Proposed

Falls du unbeherrschbare MPs vorfindest und zweifelst, ob du sie selbst korrigieren kann, melde dich im OSM-Forum, auf der Mailingliste Talk-de oder einem anderen, von der Gemeinschaft genutzten Kommunikationskanal(en) und bitte dort um Hilfe. Reparaturen missglückter Editierversuche sind immer aufwendiger als eine Vorbearbeitung durch einen erfahrenen Mapper.

https://wiki.openstreetmap.org/wiki/DE: … ipolygonen

Gruß Miche

Last edited by miche101 (2018-12-29 13:23:22)

streckenkundler · 2018-12-29 16:20:53

miche101 wrote:

Man soll einfach keine Monster bauen nur weil man es kann und gut findet... weil geht eins dieses Monster mal kaputt oder es verändert sich was. Dann ist es nicht schön diese Monster zu ändern bzw. zu reparieren.

+1

Der Hürtgenwald (eine von mehreren kaputten Relationen) https://www.openstreetmap.org/relation/116883 bzw. http://tools.geofabrik.de/osmi/?view=ar … _tags,ways

- einfach alle Inner reingekippt... https://www.openstreetmap.org/relation/ … 4&layers=N
- nicht getraut MP zu zerteilen: z.B. https://www.openstreetmap.org/relation/ … 6&layers=N und https://www.openstreetmap.org/relation/ … 0&layers=N ect...
-oder wenn eine Innerfläche fast die Outer-Fläche berührt (https://www.openstreetmap.org/relation/ … 1&layers=N)

Oftmals haben sich solche Monster auch nur im Laufe der Zeit entwickelt und keiner traut sich/macht sich die Arbeit und setzt die Schere an... Darum kann man daas nich dem letzten Bearbeiter anlasten...

Sven

rainerU · 2018-12-29 16:55:27

streckenkundler wrote:

Der Hürtgenwald (eine von mehreren kaputten Relationen) https://www.openstreetmap.org/relation/116883 bzw. http://tools.geofabrik.de/osmi/?view=ar … _tags,ways

Und wie würdest du das mappen? Viele kleine landuse=forest, jedes mit name=Hürtgenwald? Dito, aber ohne name=* an den einzelnen Landuses? Wo soll der Name dann hin?

Das Beispiel zeigt doch, dass wir viel dringender als Empfehlungen zum Umgang mit Multpolygonen praxisgerechte Empfehlungen zum Mappen von Landuses mit eingeschlossenen Landuses brauchen.

streckenkundler · 2018-12-29 17:21:10

rainerU wrote:

Und wie würdest du das mappen? Viele kleine landuse=forest, jedes mit name=Hürtgenwald? Dito, aber ohne name=* an den einzelnen Landuses? Wo soll der Name dann hin?

Nun der Hürtgenwald hat ja jetzt schon 4 Teile: http://overpass-turbo.eu/s/EPr

Das Namensproblem kann man meiner Ansicht nach nicht dadurch lösen, indem man darauf verzichtet, Riesen-MP's zu verkleinern... eine praktiable Lösung habe ich auch noch nicht parat... Das Namensproblem hat man aber bei fast allen großen Waldgebieten...
Vor allem tritt es auf, wenn durch ein Waldgebiet eine Niederungsrinne mit Seen und Bruchwald durchzogen wird... h

Ich kenn das hier von den großen Waldgebieten in Brandenburg...

Eine Idee, die in mir rumgeistert, ist eine einfache geschlossene Umgrenzungeslinie um alle Wald-Teilflächen, diese mit boundary=region + region=wood + name=XY (Relation sollte nur dann angewendet werden, wenn die Linie die 2000-Punkte-Grenze überschreitet. Inner-outer-Rollen halte ich für unnötig.

[Edit] Interessante Ecke... Die "Waldnamensvielfalt" ist/war ja echt groß: https://mapire.eu/de/map/europe-19centu … C158%2C164
Rötgener Wald, Rollesbroicher Wald, Rotter Wald, Zweifaller Wald. Kornelimünster Wald, Raerener Wald, ect...[/Edit]

Sven

Last edited by streckenkundler (2018-12-29 17:48:11)

Tigerfell · 2018-12-30 00:14:41

woodpeck wrote:

Damit ich nicht *nur* meckere, hab ich mal ein paar erklärende Worte zu dem Thema aufgeschrieben, auf http://www.remote.org/frederik/tmp/multipolygone.pdf als PDF und http://www.remote.org/frederik/tmp/multipoly.zip mit Quelldateien in SVG und ODT. Das ist jetzt sicherlich auch wieder zu viel, um direkt Teil einer Empfehlung/Richtlinie/Regel zu werden, aber vielleicht sollte man das irgendwie abrunden und dann verlinken, oder man stampft es auf eine Seite zusammen und macht es dann doch mit in den Abstimmungstext mit rein oder... Lizenz zum beliebigen Verwursten hiermit erteilt

Schön, dass die Gedenken ausformuliert wurden.

Ich finde es aber ein bisschen schwach, erst zu schreiben, dass das aktuelle Proposal nicht ausreichend kommuniziert wurde und dann aber nicht auf meine Nachfrage zu antworten. Klang meine Nachfrage zu böse oder war der Text zu lang ;-)?

Tigerfell · 2018-12-30 00:16:29

Kleine Ankündigung zwischendurch: Ich habe den Abstimmungszeitraum bis zum 1.01.19 (einschließlich) verlängert.

aeonesa · 2018-12-30 00:41:24

Bei 60% Zustimmung hat diese Maßnahme für mich diplomatisch gesagt ein gewisses Geschmäckle.

Last edited by aeonesa (2018-12-30 00:47:03)

dieterdreist · 2018-12-30 00:58:55

jedenfalls ist das nicht vorgesehen im Proposalprozess und das habe ich so auch noch nie erlebt, es sind ja ausreichend viele Stimmen abgegeben worden um der Abstimmung Gültigkeit zu erteilen.
https://wiki.openstreetmap.org/wiki/Proposal_process

Tigerfell · 2018-12-30 01:12:21

Da interpretiert ihr etwas hinein, was dort nicht steht:
Ich möchte allen Beteiligten die Möglichkeit geben, ihre Stimme abzugeben (allein am 29. haben vier Leute abgestimmt).
Wenn es bei dem aktuellen Ergebnis bleiben sollte, hat sich diese Fassung erledigt.
Ich hoffe, dass die Kommentare für andere Proposals hilfreich sein können.

Rogehm · 2018-12-30 01:24:06

"Abgelehnte Proposals können erneut zur Abstimmung gestellt, geändert und einem weiteren RFC-Prozess unterzogen werden."

Einfach unterbrechen, eine Stufe zurück, überarbeiten und noch mal starten. Das machen alle! Es können alle Kommentare belassen bleiben.
Vielleicht hängen sich ja noch andere Mapper-Kollegen rein, um da was rundzuschleifen. Ich denke, das wäre der bessere Weg.

aeonesa · 2018-12-30 01:43:33

Da interpretiert ihr etwas hinein, was dort nicht steht:
Ich möchte allen Beteiligten die Möglichkeit geben, ihre Stimme abzugeben (allein am 29. haben vier Leute abgestimmt).
Wenn es bei dem aktuellen Ergebnis bleiben sollte, hat sich diese Fassung erledigt.
Ich hoffe, dass die Kommentare für andere Proposals hilfreich sein können.

So, jetzt lege ich die Diplomatie mal beiseite, und nenne das Kind beim Namen.

Was Du machst, hat in meinen Augen nichts mit Demokratie zu tun. Du gehst hier vor, wie ein Herrscher einer Bananenrepublik, dem das Ergebnis einer Wahl nicht gefällt.

Wenn bei einer demokratischen Wahl Schluss ist, ist halt Schluss. Und wenn Du nur eine Sekunde zu spät zum Wahllokal kommst, hast Du Pech gehabt. Ich kann in den Regeln zum Proposal-Prozess auch keine Lücke sehen, die diese Vorgehensweise rechtfertigt.

Nur mal rhetorisch gefragt: Hättest Du die Abstimmung auch verlängert, wenn es ein eindeutiges Votum dafür gegeben hätte?

Mit zornigem Gruss
aeonesa

kreuzschnabel · 2018-12-30 07:58:59

aeonesa wrote:

Du gehst hier vor, wie ein Herrscher einer Bananenrepublik, dem das Ergebnis einer Wahl nicht gefällt. Wenn bei einer demokratischen Wahl Schluss ist, ist halt Schluss. Und wenn Du nur eine Sekunde zu spät zum Wahllokal kommst, hast Du Pech gehabt. Ich kann in den Regeln zum Proposal-Prozess auch keine Lücke sehen, die diese Vorgehensweise rechtfertigt.

+1. Geht gar nicht.

--ks

rainerU · 2018-12-30 09:22:00

Tigerfell wrote:

Kleine Ankündigung zwischendurch: Ich habe den Abstimmungszeitraum bis zum 1.01.19 (einschließlich) verlängert.

Ich habe gerade das Abstimmungende auf 29.12.18 24:00 gesetzt. Mir passt das Ergebnis, wie es ist.

geri-oc · 2018-12-30 10:01:14

2011 - Kurz nach dem ich mit OSM angefangen hatte:

errt wrote:

geri-oc wrote:
Und noch etwas: Auch eine "Demokratie" braucht Richtlinien.
Nur, dass wir eine Anarchie sind und deshalb keine haben, wollen und brauchen

Aber weitergebracht hat es das Wiki und OSM auch nicht.

kreuzschnabel · 2018-12-30 10:17:06

geri-oc wrote:

2011 - Kurz nach dem ich mit OSM angefangen hatte:
errt wrote:
geri-oc wrote:
Und noch etwas: Auch eine "Demokratie" braucht Richtlinien.
Nur, dass wir eine Anarchie sind und deshalb keine haben, wollen und brauchen
Aber weitergebracht hat es das Wiki und OSM auch nicht.

Anarchie heißt übrigens nicht „Es gibt keine Regeln, jeder macht einfach, was er will“, sondern Anarchie heißt „Es gibt keine Autorität, die Regeln vorschreibt, sondern wir vereinbaren unsere Regeln selbst, an die sich dann jeder, der mitmacht, selbstverantwortlich hält“.

--ks

seichter · 2018-12-30 10:46:24

kreuzschnabel wrote:

Anarchie heißt übrigens nicht „Es gibt keine Regeln, jeder macht einfach, was er will“, sondern Anarchie heißt „Es gibt keine Autorität, die Regeln vorschreibt, sondern wir vereinbaren unsere Regeln selbst, an die sich dann jeder, der mitmacht, selbstverantwortlich hält“.

Das Problem dabei ist: Wer ist "wir" und wie viele sind "jeder" .

mmd · 2018-12-30 12:56:15

Das nennt man dann wohl einen #Tigerfail

SCNR.

Last edited by mmd (2018-12-30 14:34:07)

aeonesa · 2018-12-30 14:31:25

offtopic:

Sorry, jetzt kann ich nicht widerstehen. Kurzer Hinweis in eigener Sache: @mmd:
Ich erinnere Dich an Deinen Post vor vier Tagen in der Mailingliste. Ich möchte das auch nicht, was Du nicht wolltest.

Für alle Anderen: Ist ein Insider-Gag

mmd · 2018-12-30 14:35:24

Ok, dann nehme ich deinen Text mal raus... hoffe das passt jetzt. Die beiden Nicks sind so frappierend ähnlich, da musste der dumme Kommentar einfach sein (daher auch SCNR).

Last edited by mmd (2018-12-30 14:39:34)

aeonesa · 2018-12-30 15:46:09

-gelöscht- Falsches Forum

Last edited by aeonesa (2018-12-30 15:59:01)

streckenkundler · 2018-12-30 16:46:13

... Zuerst einmal:

Ich bin gegen eine willkürliche Verlängerung des Abstimmungszeitraumes... so wie ich das sehe ist die letzte am 29.12. abgebene (und zu wertende) Stimme die von Klumbumbus.

Wenn ich richtig gezählt habe waren von 56 Stimmen 33x ja, 21x nein, 2 Enthaltungen. In meinen Augen wird sich das Ergebnis auch nicht mehr wesentlich ändern. Da es auf er anderen Seite eigentlich keine grundsätzliche totale Ablehnung vorlag, sondern es es eher inhaltliche Kritik gab (sprachliche Kritik, Mehrdeutigkeiten, Dinge, die extra behandelt werden sollten), bin ich persönlich an der Stelle dafür, das ganze "zurück in die Ausschüsse" zu verweisen. Ich will sagen, diejenigen, die inhaltliche Kritik geübt haben (die durchaus berechtigt war) sind nun gefordert, sich vor allem mit konkreten Textvorschlägen einzubringen, um einen konsensfähigen Text zu bekommen!

Wenn nicht hier, dann sollte möglichst zeitnah dazu auch parallel hinreichende Empfehlungen/ Regelungen zum "Verkleben" und "Nichtverkleben" zum Abschluß gebracht werden...

Sollte man eine Frist setzen? Ich meine ja... Nach den ewigen Disskussionen sollten wir nun doch mal langsam in der Lage sein, einigermaßen verständliche und allgemein akzeptierte Regeln zu diesen Themen zu finden und wenn es erstmal für D oder DACh ist... Dann sind wir wenigsten diejenigen, die damit anfangen... Als (unverbindliche) Frist könnte ich mir ein viertel, bis ein halbes Jahr vorstellen...

Sven

woodpeck · 2018-12-30 20:14:41

streckenkundler wrote:

Da es auf er anderen Seite eigentlich keine grundsätzliche totale Ablehnung vorlag, sondern es es eher inhaltliche Kritik gab (sprachliche Kritik, Mehrdeutigkeiten, Dinge, die extra behandelt werden sollten), bin ich persönlich an der Stelle dafür, das ganze "zurück in die Ausschüsse" zu verweisen. Ich will sagen, diejenigen, die inhaltliche Kritik geübt haben (die durchaus berechtigt war) sind nun gefordert, sich vor allem mit konkreten Textvorschlägen einzubringen, um einen konsensfähigen Text zu bekommen!

Wen ich das richtig sehe, ist das Hauptproblem, das wir lösen wollen, die übertriebene Verwendung von Multipolygonen. Die Verklebung von Linien mit Flächen ist ein Thema, das ich separat behandeln würde.

Vielleicht könnte man das Problem in Form so eines Entscheidungsdiagramms angehen, oder zumindest gedanklich mal so aufdröseln:

1. Du willst eine Fläche mappen.
2. Ist es eine Fläche mit Loch (z.B. ein Gebäude mit Innenhof) --> Multipolygon ist erforderlich.
3. Hat der Umriss der Fläche mehr als 2000 Nodes --> Multipolygon ist erforderlich
4. Hat die Fläche mehrere disjunkte Teile, aber eine gemeinsame identifizierende Eigenschaft (z.B. ein gemeinsamer Name), weswegen die disjunkten Teile nicht separiert werden können --> Multipolygon ist erforderlich

Nachdem man diese "klaren" Situationen abgehakt hat, ist man in dem "Multipolygon möglich, aber nicht notwendig"-Bereich. Vielleicht könnte man nun ein paar "auf keinen Fall Multipolygon"-Fälle abklappern:

5. Hat der Umriss der Fläche weniger als 50 (?) Nodes --> nimm einen einfachen geschlossenen Way
6. Ist die Fläche kleiner als 10 (?) qkm --> nimm einen einfachen geschlossenen Way

und dann

7. gratuliere, Du hast nun die vollkommene Wahlfreiheit

Bye
Frederik

PS Eventuell kann man 4. auch aufteilen in

4. Hat die Fläche mehrere disjunkte Teile? Nein --> Weiter bei 5, sonst

4a. haben die disjunkten Teile eine gemeinsame identifizierende Eigenschaft (z.B. diese drei Seen heissen zusammen "Die Pferdeseen", oder diese drei Flächen bilden gemeinsam das Wohhgebiet "Am Pferdeacker")? Ja --> Multipolygon ist erforderlich, Nein --> Fläche aufteilen und für jede einzelne Fläche gehe zu 1

Galbinus · 2018-12-30 20:26:19

Ich glaube, den Begriff "disjunkt" werden viele nicht verstehen.

streckenkundler · 2018-12-30 20:59:58

Hei Frederik,

Diesen Ansatz für eine Anleitung finde ich recht gut. Nicht zuletzt, weil er recht verständlich aufgebaut und bebildert ergänzt werden kann.

Bei 2 im Zusammenhang mit Gebäuden muß man aufpassen. Es gibt im Ergebnis von Gebäude-Mapping gerne die Situation, daß eine MP-Relation entsteht, mit mehreren aneinandergrenzenden Outern und ohne Inner... (duplicate Segment in Relation). Speziell für Gebäude müsste ein Verweis zu Relation type=building. Ich sehe aber als MP erfasste Gebäude als Spezialfall an und beobachte hierbei nicht allzuviele Fehler...

Sven

...dem sicher noch mehr einfällt.

Announcement

#376 2018-12-28 18:51:17

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

#377 2018-12-29 13:21:42

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

#378 2018-12-29 16:20:53

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

#379 2018-12-29 16:55:27

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

#380 2018-12-29 17:21:10

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

#381 2018-12-30 00:14:41

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

#382 2018-12-30 00:16:29

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

#383 2018-12-30 00:41:24

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

#384 2018-12-30 00:58:55

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

#385 2018-12-30 01:12:21

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

#386 2018-12-30 01:24:06

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

#387 2018-12-30 01:43:33

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

#388 2018-12-30 07:58:59

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

#389 2018-12-30 09:22:00

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

#390 2018-12-30 10:01:14

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

#391 2018-12-30 10:17:06

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

#392 2018-12-30 10:46:24

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

#393 2018-12-30 12:56:15

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

#394 2018-12-30 14:31:25

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

#395 2018-12-30 14:35:24

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

#396 2018-12-30 15:46:09

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

#397 2018-12-30 16:46:13

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

#398 2018-12-30 20:14:41

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

#399 2018-12-30 20:26:19

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

#400 2018-12-30 20:59:58

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

Board footer