Polygone mit niedrigen Nummern

Das ist die Sache von mapnik, nicht von unseren Daten. Warum sollte man überhaupt eine Waldgrenze quer durch selbigen ziehen?

+1, dann braucht man aber keine 100 geschlossenen “outer” Ringe…

Schön, dass es immer wieder Leute gibt, die im Besitz der absoluten Wahrheit sind!

Ich werde das mit dir jetzt nicht weiter diskutieren. Deine Diktion deutet mir zu sehr darauf hin, dass du Argumenten überhaupt nicht zugänglich bist. Sorry!

Mein Hauptargument gegen solche MP-Ungetüme sind schlechte Handhabbarkeit.

Ich beobachte seit einiger Zeit eine Region, wo ein Mapper versucht eine ganze Region (ca 100 km^2) mit je EINER forrest, meadow und farmland Relation abzudecken. Irgendwann ist noch eine zweite forrest Relation dazu gekommen.
http://tools.geofabrik.de/osmi/?view=multipolygon&lon=9.32241&lat=45.68839&zoom=12&overlays=invalid_geometry_hull,duplicate_ways,intersections,intersection_lines,ring_not_closed_hull,ring_not_closed,unconnected_end_nodes

Seit 2 Monaten und mit etwa 200 Changesets wird versucht, das Durcheinander in den Griff zu bekommen. Immerhin haben die beteiligten Mapper 3 davon gebändigt und kämpfen nur noch mit der “farmland” Relation (ID= 1918945)

Leider kann ich aktuell nicht sagen, wie gross die Realtion ist, da ich sie nirgens mehr geladen bekomme.

Laden in JOSM bricht meist irgendwo vermutlich wegen Timeout ab.

Anzeigen mit http://www.openstreetmap.org/browse/relation/1918945 liefert:
“Entschuldigung, es dauerte zu lange die Daten für die Relation mit der ID 1918945 abzurufen.”

Der RelationAnalizer liefert Error 502.

Dabei wäre es so einfach und vor allem fehlertollerant: etwa 100 geschlossene Wege mit landuse=farmland. Aber heute braucht man nur einen Weg zu mergen, zu löschen oder zu verlängern und das Ganze Kartenhaus bricht zusammen. Echt elegant :roll_eyes:

Ganz abgesehen davon, wie viel Platz eine Relation mit 1000 Mitgliedern und 1000 Versionen verbraucht…

mdk

Ich sage nur: KISS

Gruß von Gran Canaria, wo alles noch schoen einfach gemappt ist :laughing: :sunglasses:

Jeder dieser angeblich “um QS bemühten” Mapper sollte nur 10 Min. seiner kostbaren Zeit einer Beschreibung von Best Practice in der WIKI widmen, dann würden alle Relationen sehr schnell besser wartbar sein. Der Mangel an solchen Best Practice Beschreibungen wurde hier nun wirklich oft genug beklagt. Die einzig logische Begründung hierfür ist: es gibt eine Menge Leut die über Relationen die andere getaggt haben meckern (den TE eingeschlossen) aber niemand der sich wirklich “um QM bemüht”, denn das würde anders aussehen.

Ich komme aus einem Gebiet wo man leider nicht so leicht sagen kann, wo ein Waldstück denn anfängt und aufhört. So gibt es diese Riesen-Waldpolygone. Das hat den Vorteil dass man sich nie fragen muss, in welchem Waldpolygon man nun gerade ist…

Diese Aussage widerspricht aber deiner Aussage total, dass es sich dabei um 100 in sich geschlossene handelt.
Abgesehen davon bringt die Relation nämlich keinen Zusatzgewinn. Du könntest auch 100 Ways mit landuse=forest machen und diese in einer collection zusammenfassen. Das würde den gleichen Informationsgehalt bringen und ist außerdem robuster gegen Zerstörung.
Die Argumente vom Download hast du wahrgenommen?

Hi,

ist es angebracht, daß man wie hier z.B. http://www.openstreetmap.org/browse/relation/1862045 sieben in sich geschlossene *outer * in die Relation packt?
IMHO sollte man diese mit deren inner aus der Relation entfernen und als eigenständige Flächen bzw. Relationen erfassen.

Ist eigentlich auch meine Meinung, wobei ich auch schon vereinzelte Relationen erstellt habe mit 2 oder 3 in sich geschlossene Outer. Aber dies nur bei landuse=residential, damit man sieht, dass “fragmentierte Ortschaftsteile” eigentlich zusammengehören. Bei forest, meadow, farm usw würde ich aber auch auf mehrere Outer verzichten.

Gibts für so eine Verknüpfung nicht site-Relationen?

von der Site-Relation bin ich nicht überzeugt. Ausserdem ist die Site-Relation nichts offizielles (auch wenn es oft benutzt wird), sondern es besteht nur ein Proposal: http://wiki.openstreetmap.org/wiki/Relations/Proposed/Site

Im Prinzip ‘ja’.

Es ist nicht verboten, mehrere geschlossene outer in eine Relation zu packen, IMHO aber nur dann, wenn sie zusammen gehören. Dies sollte dann aber auch ersichtlich sein, z.B. per name. Im vorliegenden Fall und vielen anderen ist dies offensichtlich nicht so.

Wenns danach geht, dürfte so einiges nicht …

Klar sollte es für so eine verbindende Relation einen guten Grund geben.

@efred: offiziell ist etwas, wenn es in den Daten häufig vorhanden ist, nicht weil einer eine wiki-Seite dazu angelegt hat oder weil jemand in einem Forum oder einer ML drüber diskutiert hat. Wenn bei einem der Info-Kanäle ein paar tausend MApper abstimmen, könnte man diesem einen offiziellen Status geben. Das ist aber bei keinem der Fall.

1558 Elemente und über 46000 nodes.

Lade ein Element dieser Relation und den Rest per unvollständige Elemente herunterladen.

IMHO könnte man das Monster löschen, die Teile als Einzelrelationen erstellen und dabei Grenzen, soweit sie keine Tags haben zusammenfassen.

Ich hab Schwierigkeiten die Relevanz dieses Arguments zu bewerten. Beim normalen Mappen zB. in Potlatch 2 lädt der nicht die ganze Relation herunter, oder? Selbst dann hatte ich mit den von mir beschriebenen Relationen nie Probleme.

Wenn ich nicht für Renderer mappen soll, dann auch nicht für Editoren oder OSM Inspector, oder?

Okay, ich relativiere das mit den 100 geschlossenen Outer-Ringen. Es gibt Waldgebiete die dermassen ausufernd sind, die haben 20-30 outer-Grenzen für einen Ring. Da ist es dann aber genauso diskussionswürdig, sie willkürlich (z.B. an einer durch den Wald führenden Hauptstraße) enden zu lassen, oder gar an einer völlig willkürlich gesetzten Teilungslinie, wie ich das auch schon gesehen habe. Da wäre ich eher dafür, solche Relationen wieder zu verbinden.

Ich habe hier in den Diskussionen über Relationen den Eindruck, jeder denkt an andere “Extreme” die ihm beim mappen schon untergekommen sind, und so sind die Äußerungen sehr unterschiedlich und man kommt deswegen auf keinen gemeinsamen Nenner. Dabei wären sich die meisten wahrscheinlich einig ob eine Relation leicht wartbar ist, wenn man sie konkret betrachtet.

Ich weiß nur dass ich ein paar sehr schlecht wartbare Relationen getagged habe genau aufgrund der Nichtexistenz einer Best Practice Beschreibung in der WIKI. Diese waren sehr schlecht aufgrund ihrer Komplexität, mitnichten wegen der Menge der Elemente. Ich hab sie aber wegen der dort vorhanden “landuse=farmland” Riesenflächenrelationen nicht anders taggen können, und könnte es wohl heute auch nicht…

“Kleinere” Waldstücke tagge ich nie als Relationen. Auch sonst würde ich gern auf Relationen so weit wie möglich verzichten und dem Grundatz “KISS” huldigen. Aber irgendwann gibt es halt mal eine erste “inner” Fläche, und dann…

Sowohl beim direkten Laden, als auch beim Nachladen bricht JOSM (unter Windows) irgendwann ab und fängt dann immer wieder von vorne an. Unter Ubuntu geht es deutlich besser.

Wie gesagt, es sind mindestens 4 solche Relationen über das Gebiet verteilt. Ferner sind die meisten Wege ohne Tags und gehören zu mindestens 2 Relationen. Da muss man zuerst alle Flächen neu zeichnen. Danach kann man die Relation löschen und schauen was nun Ways sind, die ohne Tags sind und zu keiner anderen Relation gehören. Das Zusammenfasse der Teilwege führt unter Garantie zu Problemen in den anderen beteiligten Relationen.

Aber zum einen werde ich mir das nicht noch Mal antun (gebranntes Kind) und zum zweiten “pfusche” ich nicht gerne den dort arbeitenden Mappern ins Handwerk. Auch auf die Gefahr hin die warscheinlich gefrusteten Mapper dort zu verlieren.

mdk

Ein Editor holt nicht automatisch die gesamte Relation runter. Er lädt Ways und nodes im ausgewählten Bereich. Erst wenn man die damit angefangene Relation bearbeiten möchte sollte man die Relation vollständig herunterladen um Fehler zu vermeiden.
“Wir mappen nicht für den Renderer oder Auswerter” ist vorallem gebraucht wenn es darum geht das Bestimmte Elemente zweckentfremdet werden um dort eine gewisse Darstellung zu erreichen.
Insofern kann ich deinem Satz nicht ganz zustimmen. Man sollte natürlich nicht irgendwelchen Quatsch eintragen, damit bei OSMI kein Fehler erscheint. Und man sollte auch keine Wälder teilen, damit sie bei OSMI angezeigt werden.
Aber man sollte Daten so speichern, damit andere Mapper damit etwas anfangen können und diese Relationen auch warten und auf ihre Fehlerfreiheit prüfen können. Dies scheint bei Monsterrelationen sehr schwer zu sein. Zumal wenn die Outer des Waldgebietes in sich geschlossen sind, kann man meiner Meinung nach darauf verzichten. Es sei denn sie teilen noch weitere Eigenschaften.

Bei Grenzen gibt es übrigens auch Relationen mit sehr vielen Members. Allerdings sind diese nicht in sich geschlossen und ergeben nur in ihrer Gesamtheit dann die Fläche des Landes oder Gemeinde.

Ansonsten begrüße ich dein Statment zum KISS Prinzip. Vielleicht lassen sich die Relationen über welche hier diskutiert wird auf ein normal Maß zurecht stuzten oder gibt es Gründe das alle Waldstücke in einer Relation sind?

Man könnte ja zumindest die in sich geschlossenen outer aus der Relation http://www.openstreetmap.org/browse/relation/1862045 entfernen, oder spricht da was dagegen?

JOSM: Datei-Objekte herunterladen lädt die gesamte Relation.

Nö. Nur, wenn es angekreuzt ist. Und im normalen bbox-Download nur diejenigen Elemente, die Knoten darin haben.

Gruß,
ajoessen