x

Collection


  1. Collection · Glad (Gast) · 28.04.2012 10:36 · [flux]

    In JOSM begegnete mir die Relation "Collection". Prima, dachte ich, sie eignet sich beispielsweise, um verstreute Elemente einzusammeln, beispielsweise verstreute Bach- oder Straßenabschnitte.

    Nun lese ich unter http://wiki.openstreetmap.org/wiki/Relation:collection , dass eine Kategorisierung in OSM gar nicht gewünscht ist. Werden bestehende Collections geduldet, aber nicht aktiv unterstützt?
    Beispielsweise ist auf der WIWOSM-Diskussionsseite meine Frage noch offen, ob die Wikipedia-Tagzuordung zu einer Collection ausreichend ist, oder ob tatsächlich alle Elemente einzeln getaggt werden müssen.

    - Glad


    • Re: Collection · Tordanik (Gast) · 28.04.2012 11:34 · [flux]

      Der Warnhinweis verweist auf "Relations are not Categories". Dort geht es darum, dass Kategorien wie "Schulen in München" oder "Stolpersteine in Rostock" nicht von Hand als Relationen eingetragen werden sollen. Solche Suchen lassen sich nämlich in Geodatenbanken durch geeignete Anfragen automatisch beantworten.

      Es geht dabei nicht unbedingt um Beispiele, wie du sie nennst - also z.B. Straßenstücke mit gleichem Namen. Allerdings nutzt man auch dafür üblicherweise keine Relationen, sondern setzt das entsprechende Attribut an die einzelnen Ways und überlässt es den Anwendungen, Wegstücke mit identischen Attributen bei Bedarf zusammenzusetzen. Die collection-Relation ist eine Idee aus der Zeit kurz nach der Einführung von Relationen (als noch nicht klar war, wie sich die Einführung von Relationen auf die Konventionen beim Mapping auswirken würde) und hat sich seither nach meinem Eindruck weder beim Mapping noch in Anwendungen durchgesetzt.


    • Re: Collection · MasiMaster (Gast) · 28.04.2012 12:11 · [flux]

      Die collection- oder site-Relation (die meisten verwenden eher site) wird verwendet, um z.B. mehrere verstreute Waldstücke welche einen gemeinsamen Namen haben, zusammenzufassen. (Damit in der Datenbank nicht mehrfach der Wald XY auftaucht.) Gleiches gilt für Schulen oder Firmen, welche aus mehreren Gebäuden besehen. (building=yes an jedes Gebäude, alle Gebäude in die site, welche den Namen trägt.)


    • Re: Collection · Glad (Gast) · 28.04.2012 12:27 · [flux]

      Mit einer Collection könnte man alle Bachabschnitte und die Quelle zusammenfassen, und nur der Collection den Namen des Bachs geben (+ weitere Attribute wie z.B. Verweis auf Wikipedia).

      Aus den Antworten schließe ich, dass das nicht gewünscht ist und eine Collection eine redundante Zusatzinformation ist.


    • Re: Collection · Fabi2 (Gast) · 28.04.2012 12:52 · [flux]

      Glad wrote:

      Mit einer Collection könnte man alle Bachabschnitte und die Quelle zusammenfassen, und nur der Collection den Namen des Bachs geben (+ weitere Attribute wie z.B. Verweis auf Wikipedia).

      Für das Zusammenfassen von Fließgewässern gibt es https://wiki.openstreetmap.org/wiki/Rel … d/Waterway


    • Re: Collection · Glad (Gast) · 28.04.2012 13:16 · [flux]

      Es gibt:

      • Relations/Proposed/Waterway für Fließgewässer
      • site (Veraltet)
      • weitere?
      • Collection für alles andere? Beispiele: Straßen, historische Straßen, Gleise, alte Gleise...

      Wer oder was nutzt die Kollektionen? Im Augenblick sehe ich nur den Sinn, das Projekt WIWOSM zu unterstützen.


    • Re: Collection · wambacher (Gast) · 28.04.2012 14:07 · [flux]

      Glad wrote:

      Wer oder was nutzt die Kollektionen? Im Augenblick sehe ich nur den Sinn, das Projekt WIWOSM zu unterstützen.

      Das Hauptproblem bei Collection-Relationen (egal ob collection, site, waterway, associated_street, Stolpersteine, hkts, ...) ist die Pflege der Member.
      Es kann nie sicher gestellt werden, dass diese Liste vollständig ist. Einerseits vergisst man bei Mappen den zusätzlichen Eintrag (ging mir bei associated_street so) oder der Mapper weiss überhaupt nicht, dass es eine Sammel-Relation dazu gibt. Nur beim Löschen -und nur dann!! - bemerkt die Software das, aber NIE beim Eintragen.

      Der Editor, der nachfragt "Du hast da gerade ein Bachstück eingetragen, willst du den auch noch hier einfügen?" muss erst noch geboren werden.

      Daher ist der OSM-Ansatz, sich solche Information aus der Geometrie/Lage und den Tags der Objekte rauszuholen. Selbst die Beispiele von WIWOSM bestehen aus Abfragen und nicht aus manuell gepflegten Listen.

      TL;DR Vergiss es

      Gruss
      Walter


    • Re: Collection · Radeln (Gast) · 28.04.2012 14:16 · [flux]

      MasiMaster wrote:

      Die collection- oder site-Relation (die meisten verwenden eher site) wird verwendet, um z.B. mehrere verstreute Waldstücke welche einen gemeinsamen Namen haben, zusammenzufassen. (Damit in der Datenbank nicht mehrfach der Wald XY auftaucht.) Gleiches gilt für Schulen oder Firmen, welche aus mehreren Gebäuden besehen. (building=yes an jedes Gebäude, alle Gebäude in die site, welche den Namen trägt.)

      Wobei die site nicht erforderlich ist, wenn z.B. die Schulgebäude in einer Fläche liegen, die mit amenity=school getaggt ist.


    • Re: Collection · fkv (Gast) · 30.04.2012 07:18 · [flux]

      wambacher wrote:

      Das Hauptproblem bei Collection-Relationen (egal ob collection, site, waterway, associated_street, Stolpersteine, hkts, ...) ist die Pflege der Member.
      Es kann nie sicher gestellt werden, dass diese Liste vollständig ist.

      Wenn ich 5 nebeneinander stehende Felsblöcke habe, die "5 Brüder" heißen, kann ich mir ziemlich sicher sein, dass kein weiterer hinzukommt. Das von dir angesprochene Problem betrifft eher weit verstreute Objekte, oder solche mit sehr vielen Members. Das lässt sich manchmal nicht vermeiden, bei Routenrelationen ist es ja auch so. Ob man Bachabschnitte unbedingt zusammenfassen muss, sei einmal dahingestellt.

      Der Editor, der nachfragt "Du hast da gerade ein Bachstück eingetragen, willst du den auch noch hier einfügen?" muss erst noch geboren werden.

      Ich finde Editoren, die ein Eigenleben entwickeln (d.h. JOSM), sowieso gefährlich. Man sollte sich angewöhnen, selber zu denken statt das ganz dem Editor zu überlassen.