Relation; type=collection

Fabi2 · 2011-02-10T17:02:12.000Z

hurdygurdyman:

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.

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.

viw · 2011-02-10T17:33:50.000Z

hurdygurdyman:

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.

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.

fkv · 2011-02-10T17:46:56.000Z

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

hurdygurdyman · 2011-02-10T18:21:23.000Z

Fabi2:

…
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.

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

Fabi2 · 2011-02-10T18:50:25.000Z

hurdygurdyman:

Fabi2:

…
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.

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.

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.

Nop · 2011-02-10T18:59:14.000Z

hurdygurdyman:

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.

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

bye
Nop

hurdygurdyman · 2011-02-11T08:05:17.000Z

Fabi2:

…
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.

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?

Fabi2 · 2011-02-11T13:13:02.000Z

hurdygurdyman:

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 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.

hurdygurdyman · 2011-02-11T13:45:28.000Z

Fabi2:

…
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.

Fabi2 · 2011-02-11T14:12:05.000Z

hurdygurdyman:

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.

Nein, das abstellen eines Polizisten für jeden Mapper kann auch nicht die Lösung sein, genau so wenig das unüberlegte Übernehmen der ausdiskutierten Mehrheitsmeinung, wenn man selbst was besseres gefunden hat. Da verhindern dann deine klaren Prozesse den Fortschritt, weil der abgestellt Polizist was neues Besseres einfach verbietet. Ist ja mit der Demokratie auch so.

hurdygurdyman:

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.

Da wiedersprichst du dir aber, zum einen willst du die schlecht definieret site-Relation benutzen und zum dann aber ingesamt saubere Daten.

hurdygurdyman · 2011-02-12T16:09:34.000Z

Fabi2:

…
Nein, das abstellen eines Polizisten für jeden Mapper kann auch nicht die Lösung sein, genau so wenig das unüberlegte Übernehmen der ausdiskutierten Mehrheitsmeinung, wenn man selbst was besseres gefunden hat. Da verhindern dann deine klaren Prozesse den Fortschritt, weil der abgestellt Polizist was neues Besseres einfach verbietet. Ist ja mit der Demokratie auch so.

Wie du aufgrund meiner Ausführungen darauf kommst, dass ich OSM-Polizisten fordere und jeden Fortschritt bzw. jede Weiterentwicklung verhindern will, kann ich nicht nachvollziehen.

Wahrscheinlich haben wir schon babylonische Verhältnisse

Fabi2:

…
Da wiedersprichst du dir aber, zum einen willst du die schlecht definieret site-Relation benutzen und zum dann aber ingesamt saubere Daten.

Auch nach dreimaligem Lesen dieses threads finde ich nirgendwo, dass ich die site-relation ins Spiel brachte. Der Vorschlag kam von dir…

Fabi2 · 2011-02-13T21:44:16.000Z

hurdygurdyman:

Fabi2:

…
Nein, das abstellen eines Polizisten für jeden Mapper kann auch nicht die Lösung sein, genau so wenig das unüberlegte Übernehmen der ausdiskutierten Mehrheitsmeinung, wenn man selbst was besseres gefunden hat. Da verhindern dann deine klaren Prozesse den Fortschritt, weil der abgestellt Polizist was neues Besseres einfach verbietet. Ist ja mit der Demokratie auch so.

Wie du aufgrund meiner Ausführungen darauf kommst, dass ich OSM-Polizisten fordere und jeden Fortschritt bzw. jede Weiterentwicklung verhindern will, kann ich nicht nachvollziehen.

Gut, das war überspritzt, ist aber die Konsequenz aus deinen oben gemachten Forderungen, unabhängig davon, ob die sie jetzt nachvollziehen kannst oder nicht.

hurdygurdyman:

Fabi2:

…
Da wiedersprichst du dir aber, zum einen willst du die schlecht definieret site-Relation benutzen und zum dann aber ingesamt saubere Daten.

Auch nach dreimaligem Lesen dieses threads finde ich nirgendwo, dass ich die site-relation ins Spiel brachte. Der Vorschlag kam von dir…

Was’n jetzt Trollmode on?
Hab ja auch nicht behauptet, daß du die site-Relation ins Spiel gebracht hast. Du hast dich aber dazu geäußert und darauf bezieht sich auch die Antwort.
Solche Ablenkungsmannöver verhindern auch nicht, das man die Widersprüche sieht.

So, jetzt genug gefüttert…

hurdygurdyman · 2011-02-14T04:43:58.000Z

Fabi2:

…
gut, das war überspritzt, ist aber die Konsequenz aus deinen oben gemachten Forderungen, unabhängig davon, ob die sie jetzt nachvollziehen kannst oder nicht.
…
Hab ja auch nicht behauptet, daß du die site-Relation ins Spiel gebracht hast. Du hast dich aber dazu geäußert und darauf bezieht sich auch die Antwort.
Solche Ablenkungsmannöver verhindern auch nicht, das man die Widersprüche sieht.
…

Die Konsequenz sehe ich nicht…
Sobald mehrere Menschen erfolgreich an einer Sache arbeiten, ist ein Mindestmaß an möglichst demokratischer Organisation, Absprachen und Regeln erforderlich, die durch Erfahrungen ständig der jeweiligen Situation und Entwicklung anzupassen sind, wonei auch Irrwege verlassen werden können.

Meine Äußerungen zu site waren zur Verwendung in diesem Zusammenhang durchgehend ablehnend. (siehe #30 und #33)

miraculixOSM · 2011-02-14T14:14:19.000Z

hurdygurdyman:

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?

Über Anwenderfreundlichkeit kann man/frau eigentlich gar nicht genug diskutieren. Von daher halte ich deine abschließende Frage auch für mehr als berechtigt.

In diesem Sinne erscheint es mir gerade auch bei Relationen angebracht, diese so klar und einfach wie möglich zu gestalten. Schwer voneinander abgrenzbare Relationstypen widersprechen dem. Mit dem Vorschlag, type=collection auch für Objektsammlungen zu verwenden, könnte ich mich deshalb durchaus anfreunden

Radeln · 2012-03-08T14:55:32.000Z

hurdygurdyman:

Fabi2:

…
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.

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

Da muß ich Fabi2 eindeutig recht geben. Nur in der deutschen Relationsübersicht ist nur von Gebäuden die Rede. Auf der englischen Seite steht das: A way to group elements (nodes/ways/areas/relations).

Ergo ist die ‘collection’ in dieser Hinsicht überflüssig. Gilt IMHO auch für die ‘building’, die man genauso gut mit der ‘site’ darstellen kann. Ob man dann bei der Bezeichnung ‘site’ bleibt, ist eine andere Sache.

Fabi2 · 2012-03-08T17:42:12.000Z

Radeln:

Da muß ich Fabi2 eindeutig recht geben. Nur in der deutschen Relationsübersicht ist nur von Gebäuden die Rede. Auf der englischen Seite steht das: A way to group elements (nodes/ways/areas/relations).

Ergo ist die ‘collection’ in dieser Hinsicht überflüssig. Gilt IMHO auch für die ‘building’, die man genauso gut mit der ‘site’ darstellen kann. Ob man dann bei der Bezeichnung ‘site’ bleibt, ist eine andere Sache.

Das man das vor allem nicht wirklich sinnvoll auswerten und sich damit eigentlich auch komplett sparen kann, dürfte hoffentlich auch klar sein.

hurdygurdyman · 2012-03-08T17:53:40.000Z

Fabi2:

Radeln:

Da muß ich Fabi2 eindeutig recht geben. Nur in der deutschen Relationsübersicht ist nur von Gebäuden die Rede. Auf der englischen Seite steht das: A way to group elements (nodes/ways/areas/relations).

Ergo ist die ‘collection’ in dieser Hinsicht überflüssig. Gilt IMHO auch für die ‘building’, die man genauso gut mit der ‘site’ darstellen kann. Ob man dann bei der Bezeichnung ‘site’ bleibt, ist eine andere Sache.

Das man das vor allem nicht wirklich sinnvoll auswerten und sich damit eigentlich auch komplett sparen kann, dürfte hoffentlich auch klar sein.

Ein Jahr später
Ändert leider alles nichts an der Tatsache, dass site begrifflich unsauber für “Gruppieren von Elementen” ist:
http://dict.leo.org/ende?lp=ende&lang=de&searchLoc=0&cmpType=relaxed&sectHdr=on&spellToler=&search=site

Aber bei uns sind ja auch Trampelpfade highways…

Fabi2 · 2012-03-08T18:08:47.000Z

hurdygurdyman:

Fabi2:

Das man das vor allem nicht wirklich sinnvoll auswerten und sich damit eigentlich auch komplett sparen kann, dürfte hoffentlich auch klar sein.

Ein Jahr später

Das Nachsehen auf den nach Möglichkeit englischen (weil die sind meistens ausführlicher und genmauer bzw. noch mehr an der Orginalvorlage) und deutschen Wikiseiten bzw. den Ursprungsproposaln (weil die Tagseiten werden dann auch gerne mal, nicht unbedingt immer sinnvoll, auf der englischen Wikiseite passend an die eigenen Interpretation angepaßt) kann ich den Leuten leider nicht abnehmen, genausowenig wie das hezielte Nachfragen.

hurdygurdyman:

Ändert leider alles nichts an der Tatsache, dass site begrifflich unsauber für “Gruppieren von Elementen” ist:
http://dict.leo.org/ende?lp=ende&lang=de&searchLoc=0&cmpType=relaxed&sectHdr=on&spellToler=&search=site

Aber bei uns sind ja auch Trampelpfade highways…

Endscheidend ist die sprachliche Bedeutung nur bei der Erstellung neuer Proposals bzw. bei der freien Eigenerweiterung von vorhandenen Keys. Für den Rest sollte man die
Definition aus dem Wiki benutzen. Sieh z.B. mal die Tags von power=* im Wörterbuch nach.

hurdygurdyman · 2012-03-08T18:33:52.000Z

Fabi2:

Endscheidend ist die sprachliche Bedeutung nur bei der Erstellung neuer Proposals bzw. bei der freien Eigenerweiterung von vorhandenen Keys. Für den Rest sollte man die
Definition aus dem Wiki benutzen. Sieh z.B. mal die Tags von power=* im Wörterbuch nach.

Die Sinnhaftigkeit des Begriffes wird ja auch in der Diskussion schon in Frage gestellt: http://wiki.openstreetmap.org/wiki/Talk:Relations/Proposed/Site
Diese vier Jahre alte proposal ist immer noch nicht entschieden, wird aber schon heftigst angewendet
Und power zeigt, wie unüberlegt begriffliche Schnellschüsse zu unsauberen Termini führen, die dann wieder durch Fehlinterpretation Datenmüll hinterlassen und unnötige Diskussionen und Erklärungen nach sich ziehen.

Ich sage noch einmal: Babylon…

Fabi2 · 2012-03-08T19:02:17.000Z

Die Idee, hinter type=site, wenn man die Ergänzung von vor einem Jahr über die komplexeren Fälle zugrunge legt, ist ja daß man mehre unabhängige Objekte (der gleichen Art (also gleicher Tag) wäre sinnvoll, ist aber nicht so defniert) übergeordenet mit gemeinsamen Tags versehen kann. Das würde aber ersordern das man die Ursprungsflächen dann eben nicht mehr mit z.B. amenity=school + name=* taggt, weil das ja redundant wäre, wie lange es aber dauert, bis der erste Mapper den fehlenden Tag an der Fläche ergänzt, weil es nicht grendert wird, könnt ihr euch bestimmt denken. Außerdem wurde da ja schon gemäß englischer Definition bestimmt schon min. 3 Jahre ordentlich Müll in die Datenbank gekippt.