Relation; type=collection

Sorry, du hast recht. type=* ist als key der Relation zuzuordnen. Hängt vielleicht damit zusammen, dass der Begriff Multipolygon außerhalb der OSM-Welt eine Zusammenfassung mehrerer Polygone bedeutet, die sich nur in Punkten berühren dürfen. Das MP selbst hat dabei kein Flächenmerkmal. :confused:
(Ich lese mich ein… :wink: )
http://www.slidefinder.net/G/Geoinformation_III_Vorlesung/5859813
Somit mag der in OSM verwendete “Begriffs-Dialekt” als Erklärung und Entschuldigung genügen.

edit: link hinzugefügt

Hallo ajoessen,
unter welchem Punkt oder Unterpunkt siehst du dort den Lösungsansatz?

The relation itself can have a number of tags, the most important of which is the type.

aus:
http://wiki.openstreetmap.org/wiki/Relation

ok, hab mich bei MP’s verguckt.
“can have” heißt “kann haben”, muss somit nicht…

Die established passen nicht :frowning:
…und welches der proposed kommt da deiner Meinung nach in Frage? Hier geht es doch primär um den Namen des gesamten Bodensees. So etwas wie type=region oder type=area könnte passen, dass dann auch für z.B. den Harz oder ähnliches verwertbar wäre.

Wie gesagt, type=collection wäre ok, wenn’s denn nicht blöderweise auf ways beschränkt wäre.

Wenn’s also noch nix passendes gibt muss man halt was erfinden.
type=collection2 / area_collection / mp_collection … der Phantasie sind keine Grenzen gesetzt. :wink:

Deinen Vorschlag type=region finde ich auch nicht schlecht.
Könnte auch zB hier bei der ostfriesischen Insel - Collection verwendet werden,
welche zur Zeit als MP eingetragen ist.

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

Eigentlich möchte ich genau darauf verzichten, den in der GIS-Welt außerhalb von OSM gilt, dass ein Multipolygon mehrere Polygone zusammenfasst, die wir als Element für Flächen (noch) nicht haben solange wir ways als geschlossene Linie dazu “missbrauchen”, wodurch die Probleme entstehen.
Guggsdu:
http://www.slidefinder.net/G/Geoinformation_III_Vorlesung/5859813
Seite 2

Siehe meinen Beitrag auf der Diskussionsseite
http://wiki.openstreetmap.org/wiki/Talk:Relations/Proposed/Collected_Ways.

Naja, manche der Leute, die Relationen als Kategorien mißbrauchen, benutzen gerne type=set dafür, zumindest hab ich das schon gesehen.

ich bin auch dafür, dass dies allgemeiner verwendet werden kann. auf meinem kleinen test-flecken wo ich gerade mit micromapping herumspiele, wäre das speziell bei den exakt eingezeichneten parkplatzflächen hilfreich um die beschriftung auf karten nur einmal anzeigen zu lassen: http://www.openstreetmap.org/browse/relation/1417634

Solange wir nichts besseres haben, denke ich, dass type=collection wohl das richtige ist. Es gibt m.E. auch keinen Grund, die Beschränkung auf ways beizubehalten. Das würde sich auch mit meiner Grundeinstellung “weniger ist mehr” decken. Und warum was neues erfinden, das nur zur Verwirrung beiträgt und es den mappern noch schwerer macht, wenn Vorhandenes durch eine allgemeinere Definition den Zweck erfüllt.

Ich packe type=collection wieder drauf. Wer ändert die Definition?

P.S. Auch wenn’s schön aussieht. Micromapping mit Zäunen, Gartentüren halte ich für etwas überzogen. Fehlen nur noch die Gullideckel mit Anzahl, Breite und Ausrichtung der Schlitze, damit ein Hundebesitzer vorher checken kann, ob sein Pinscher da möglicherweise durchfällt.

es gibt sehr wohl anwendungsbereiche für detailierte karten. siehe dazu: http://forum.openstreetmap.org/viewtopic.php?id=10522

Dafür gibt es doch die type=site-Relation, da kann man nach Lust und Laune alle Objekte reinpacken, wo man denkt, das sie zusammen gehören, seinen es zusammengehörige Haltestellen, Schulen (mit oder ohne Schulhofbestandteilen wie Bäume, Speilplätze, Nebenbauten, etc.) oder Militärbasen, in einer Site-Relation ist für alles Platz. Leute wie !i! sehen auch solche aus meiner Sicht, Datenmüllhalden nicht als schlimm, sondern als interessantes Experimentierfeld für Anwendungen an. So das man die besten Gewissens auch dafür benutzen kann, denn schließlich gehören die Mutlipolygon-Bestandteile ja auch zusammen, also darf man sie auch in eine Site-Relation packen. Da braucht man auch type=collection nicht zu ändern, weil es gibt ja die gute Site-Relation. :wink:

Also gerade die Gullideckel wären sehr sehr interessant. Es soll da Städte geben die haben eigens dafür ein Kamerafahrzeug losfahren lassen, um auf diese Art im Winter unter Schnee und nicht ablaufendem Schmelz-/Regenwasser diese Dinger zu finden. Denn nur so ist es möglich für einen reibungslosen Ablauf zu sorgen.

http://wiki.openstreetmap.org/wiki/Key:manhole (falls es wer noch nicht kennt)

site (Ort usw. siehe:dict.cc | site | English Dictionary )
fasst laut wiki Gebäude auf Flächen zusammen, was noch mehr daneben liegt als collection, das zumindest vom Sprachgebrauch allgemeiner Sammlung bedeutet und somit als “Lumpensammler” oder “Daten-Müllhalde” taugt.

Die Babylonier wollten hoch hinaus und einen Turm bis in den Himmel bauen. Dann wurde ihre Sprache wegen dieses Übermutes verwirrt und die Babylonier verstreuten sich über die ganze Erde. Der Turm wurde nie fertig und das große Volk ging unter.

Ich hoffe, OSM und seiner Gemeinde geht’s nicht genauso :wink:

Der Hindergrund war der hier. Auf der sprachlichen Ebene sind gerade die Relationsbezeichnungen meist es so kurz und zu abstrakt, um sie als sinnvolle Erklärung heran zu ziehen, man könnte da ja auch type=set nehmen, das heißt ja auch Satz, Menge, etc. und wird schon inoffiziell eben als Kategorie-Relation verwendet.

Weil letztlich ist doch eine Site-Relation quasi nur der Hinweis an den Renderer, den Namen in der Mitte des Polygongebildes zu platzieren, wenn man site wörtlich nimmt, ist das ja auch nur ein Ort, also als Sammelrelation für mehrere Standorte ist das nicht zu gebrauchen. Sinnvolle Metadaten kann man da ja mangels klarer Definition dessen, in welcher Beziehung die Objekte stehen und um was für Objekte es sich überhaupt handelt ja auch nicht wirklich daraus gewinnen.

Sehr schöner Vergleich! Und die Babylonier hatten noch nicht mal eine Lizenzdiskussion! :slight_smile:

bye
Nop

Ich weigere mich und rate davon ab, irgendwelche noch nicht ausdiskutierten Ideen aus propsals zu verwenden.
Ich nehme site wörtlich. site ist ein “Ort” trotz mehrerer anderer deutscher Bedeutungen, von denen aber keine für einen großen See zutrifft. Im konkreten Fall ist die Relation auch nicht nur dazu da, den Namen für Renderer zu plazieren, sondern beschreibt konkrete geografische und sprachliche Fakten. Collection als Sammlung passt.

Ich möchte hier jetzt aber nicht schon wieder eine Grundsatzdiskussion über die Anwenderfreundlichkeit der Wiki, klare Begriffsdefinitionen und weitere Unwägbarkeiten in OSM anfangen…

Als abschließende Frage sei mir aber erlaubt:
Wie soll da der engagierte Laien-Mapper noch mitkommen und wie sollen menschliche und maschinelle Anwender das alles verarbeiten?

Ich wollte ja nur warnen, das dabei langfristig Datenmatsch heraus kommt. Klar sollte man seine eigene Taggingmeinung immer irgendwelchen Vorschlägen vorziehen, wenn man sie nicht nachvollziehen kann. Du darfst da anderer Meinung sein, aber das was ich geschrieben habe, ist was im Endeffekt dabei heraus kommt, wenn du dir mal überlegst, wie da das sinnvoll automatisiert auswerten kannst.

Datenmatsch haben wir schon, weil eben jeder seine eigene Taggingmeinung hat und dann auch noch verwendet. Meine Meinung habe ich zu sauberen Prozessen von der Erfassung bis zur An-/Auswertung schon mehrfach geäußert.

Genau die automatisierte Auswertung habe ich vor Augen, wenn ich lediglich andiskutierte Vorschläge nicht verwende. Und da hatte ich, wie du oben siehst, schon bei collection Bauchweh.

Mindesten 50% der Fragen und (nicht zu Ende) geführten Diskussionen hier würden wir uns sparen, wenn hier nicht jeder machen könnte, was er will. Auch und gerade ein freies Projekt mit engagierten Laien benötigt im Interesse des Projekterfolgs klare Prozessbeschreibungen, Definitionen und Grenzen.

Im Grunde wollen wir wohl dasselbe, haben aber nur noch keinen gemeinsamen Weg gefunden.