DE talk:Types of relation

Gruppen von Gebäuden

Wie sieht das aus, können /sollen Relationen auch verwendet werden, um die Zugehörigkeit von mehreren Gebäuden zu einer best. Gruppen zu bestimmen ? Ich denke da z.B. an Gebäude auf Krankenhausgeländen, Kasernen, Universitäten. Letztere sind ja oftmals über das gesamte Stadtgebiet verstreut...--TKN 15:38, 22 October 2008 (UTC)

Es gibt Relations/Proposed/Site, um Einrichtungen, die zu einem Schul-/Uni-/Krankenhaus-/…-Gelände gehören, zu gruppieren. Für räumlich halbwegs zusammenliegende Dinge würde ich das auch verwenden – bei der „über das ganze Stadtgelände“ verteilten Variante wahrscheinlich nicht – das geht eher in die Richtung „gleicher Betreiber“, aber ist kein zusammengehöriges Gelände. --Tordanik 22:17, 23 October 2008 (UTC)

Danke. Interessant war für mich die Frage, ob man durch geschicktes Taggen Gebäude hinterher mal selektieren kann, d.h., z.B. alle Universitätsgebäude automatisch hervorheben, um sie evtl. in einer Campuskarte darzustellen. Über Operator würde man dies ja sicher erreichen können... --TKN 09:53, 30 October 2008 (UTC)

Fluesse

Wie sieht es eigentlich mit Fluessen aus? Sollten die nicht auch in eine Relation aufgenommen werden?

Sollte dann natuerlich auch fuer Kanaele gelten. Hashier 17:42, 14 April 2009 (UTC)

Und welche Information würde diese Relation tragen außer "diese Flussstücke tragen den gleichen Namen und hängen zusammen" -- was man auch ohne Relation erkennt? --Tordanik 18:21, 14 April 2009 (UTC)

z.b. die Oker ist in einer Relation und ich finde das eigentlich sehr nett, so kann ich in Josm die Relation runterladen und dann sagen er soll in einem Umkreis von 50metern auch alles runterladen und ich habe dann ein OSM File von nur den Daten, kann man dann z.b. ganz toll auf das GPS laden und hat nur die Daten, oder ich find es schoen wenn man sich die Komplette Umgebung anschauen kann wo ein Fluß oder Kanal langlaeuft, ich kam vorher noch nie auf die Idee den Mittellandkanal zu folgen, musste dann aber feststellen, das es keine Relation ist wie die Oker und des Verfolgen nicth so einfach war wie bei der Oker. Also eigentlich spricht nichts dagegen, wenn ich den Mittellandkanal in einer Relation packe. Hashier 10:29, 15 April 2009 (UTC)

Es macht mehr Arbeit, weitere Teile des Flusses einzuzeichnen. (Und wenn das jemand vergissst oder nicht weiß, gibts womöglich Duplikate.) Da es technisch auch möglich wäre, in JOSM/API eine Funktion "lade alle Flussstücke mit Namen X runter" einzubauen, sehe ich es als den falschen Weg an, hier Arbeit vom Computer auf den Mapper zu verlagern. --Tordanik 10:31, 15 April 2009 (UTC)

Gute Frage. - Beim Einzeichnen eines Flusses wird dieser vermutlich in vielen einzelnen Stücken eingetragen, die sich nur nach und nach zusammenfügen. Eine Relation ermöglicht es, Gewässer in ihrer Gesamtheit von der Quelle bis zur Mündung aus dem Datenbestand abzurufen. Ohne Relation ist das unmöglich. Wenn sie noch nicht vollständig erfaßt sind, erkennt man die Lücken oder unverbundene Abschnitte. Auch für die Erstellung thematischer Karten könnten Relationen für Gewässer interessant sein. --elmada 19:10, 14 April 2009 (UTC)

Eine Funktion "lade alle Flussstücke mit Namen X" einbauen nutzt wenig, wenn das Gewässer streckenweise den Namen wechselt und verschiedene Gewässer mit gleichem Namen auftauchen. Routen-Relationen gehen weit über diese simple Datenabfrage hinaus. Die Erstellung einer Routen-Relation ist das beste Mittel, um die Zusammengehörigkeit vieler Elemente sichtbar zu machen. Ein Gewässer-Element mit einem Routen-Tag zu versehen, ist nicht mehr Arbeit, wie seinen Namen einzutragen. Die Erstellung einer Route ist nur ein einziges Mal Arbeit. Für's erste reicht es, nur die wichtigsten übergeordneten Infos zu erfassen. Wer mag, kann die Routen-Tags nachträglich überarbeiten. Praktisch: die enthaltenen Infos sind anschließend von allen damit verknüpften Teilelementen aus abrufbar. Mit Hilfe des Routen-Checks können alle zugehörigen Elemente auf verschiedenen Karten angezeigt werden. Lücken oder unverbundene Elemente werden dabei sofort sichtbar. Das erleichtert die Erfassung einer Route sehr. Auch kann eine Route als *.gpx herunter geladen werden. Diese Aussicht motiviert möglicherweise so manche/n, sich die Mühe zu machen, eine lückenhafte Route auszubessern. (Motivation zur Qualitätssteigerung ^^) Nicht jede/r arbeitet mit Josm. In Potlach kann man sich mit Hilfe der Routen-Relation die zugehörigen Elemente im Liniengewirr durch Farbmarkierung hervorheben lassen. ... Die in Josm an Routen gekoppelten Möglichkeiten sind noch wesentlich komfortabler. Warum also nicht nutzen? Sehe darin keine Mehrbelastung des Mappers. Wer dazu keine Lust hat, soll es einfach lassen.

Wer an einer Routen-Erfassung interessiert ist, sollte sie anlegen. Doch nicht voreilig. Vor dem Anlegen einer Route sollte man sich stets die Arbeit machen, herauszufinden, ob bereits eine entsprechende Route angelegt wurde. Um diese Arbeit zu erleichtern, könnte man Fluß-Routen in eine eigene Übersichtsliste eintragen. (sortable !!! Wiki-Tabelle) Am besten mal die verschiedenen Wander-Routen-Listen ansehen. Da gibt es praktische und unpraktische Formen. Bei der Erfassung von Fernrouten wurden Probleme diskutiert, die auch bei der Erfassung großer Gewässersysteme auftauchen können. Daher sicherlich interessant. --elmada 12:08, 15 April 2009 (UTC)

Kommt spät aber hier werden Flußrelationen gesammelt: WikiProject Germany/Gewässer

type=nation ?

Ich möchte den Datensatz von OSM zum Rendern eigener Karten für Wikivoyage benutzen. Zur Zeit bin ich noch dabei, einen Überblick über die Datenstruktur zu bekommen. Mir ist dabei die 7887 7887 ("Deutschland") aufgefallen, weil sie zunächst einmal so ziemlich alles an die hardwaremäßigen Grenzen gebracht hat, was man sich nur vorstellen kann. Nachdem ich es mit einigen Tricks doch geschafft habe, zu sehen, was da alles drin ist, haben mir die Haare zu Berge gestanden. Ich bin mir sicher, dass auch diese Ralation einen tieferen Sinn hat, nur ist mir vollkommen unklar, welchen. Nun also die Frage eines OSM-Anwenders: Was hat es mit "type=nation" und speziell mit dieser Relation auf sich? -- Hansm 18:07, 24 July 2009 (UTC)

Da hatte eben jemand die Idee, eine Relations-Hierarchie zur Abbildung von politischen Gegebenheiten anzulegen (Deutschland enthält die Relationen der einzelnen Bundesländer, die wiederum kleinere Einheiten etc.). In jeder Relation könnte man dann Informationen wie Hauptstädte sauber eintragen.

So richtig durchgesetzt hat sich das offensichtlich nicht, so dass man auf diese Weise keine vollständigen Daten erhält. Liegt wohl neben der komplexen Handhabung in Editoren vor allem daran, dass es an einer bekannten Software fehlt, die das auch wirklich benutzt. Bedenke bei so was am besten immer, dass in OSM jeder mehr oder weniger beliebig eigene Tags erfinden kann, so dass nicht jede in der Datenbank anzutreffende Information Teil eines Gesamtkonzepts ist.

(Übrigens: Das Wiki ist nicht gerade die Anlaufstelle, wenn du schnelle Antworten haben willst. Damit ist in Mailingliste oder Forum eher zu rechnen.) --Tordanik 15:42, 26 July 2009 (UTC)

Auf Grund meiner Herkunft liegt mir das Wiki wesentlich besser als Kommunikationsmittel als Mailinglisten. Ich versuch's also nochmal hier. Ich sehe OSM eher von der Seite des Nutzers. Da stellt sich mir die Frage, was man überhaupt mit einer solchen Relation anfangen kann. Falls es bezüglich Tags und Verwendung von Relations so was wie eine authorisierte Instanz gibt, würde ich am ehesten die entsprechenden Seiten dieses Wikis als solche ansehen. Da gibt es z.B. auch Relations/Relations are not Categories. Bei Relation 7887 habe ich das Gefühl, dass sie eher als Kategorie ge-/miss-braucht wurde.

Grundsätzlich weiß ich immer noch nicht so richtig, was ich von der Philosophie halten soll, dass jeder seine Tags beliebig setzen oder weglassen kann. Einerseits weiß ich aus eigener Erfahrung, dass man bei Open Content Projekten niemanden zu etwas zwingen kann und Freiraum für die persönlichen Ideen der Autoren/Mapper lassen muss. Andererseits erschwert die uneinheitliche Verwendung von Tags eine Benutzung der an sich sehr ergiebigen Datenbank erheblich. Maschinen können eben schlecht erraten, welche Bedeutung ein unbekanntes Tag haben könnte. Da stört alles, was von der Norm abweicht. Letztendlich bleibt nur das, was Mapnik, Osmarender & Co machen, nämlich einen selbstdefinierten Satz von Tags auszuwerten und den Rest einfach zu ignorieren.

-- Hansm 20:19, 27 July 2009 (UTC)

Genau so - einen Satz von Tags auszuwerten und den Rest zu ignorieren - ist das auch ja gedacht. Auf diese Weise stört ein experimentelles Tag (bzw. eine Relation) nämlich nicht weiter - auch Performanceprobleme dürften am Ausgang eines primitiven Whitelist-Filters verschwinden. Sinnvoll ist das ohnehin, denn selbst wenn nur durch eine zentrale Autorität genehmigte Informationen in der Datenbank stünden, würden nicht alle Arten von Anwendungen alle Informationen brauchen: Was will der Fahrradrouter mit den Hochseebojen?.

Also: Überlegen, was für Informationen deine Anwendung braucht -> die relevanten OSM-Tags dafür finden -> genau diese Tags auswerten. Diese Vorgehensweise kommt ohne ein Entscheidungsgremium mit all seinen Nachteilen aus. --Tordanik 08:10, 28 July 2009 (UTC)

OK, das scheint der einzig gangbare Weg zu sein. Aber an dem Wirrwarr mit Tags an Grenzlinien habe ich trotzdem hart zu beißen. Es wird alles andere als einfach, hier die Infos herauszufiltern bzw. zu deduzieren, die ich haben möchte. Ich werde wohl oder über damit leben müssen und versuchen, das beste daraus zu machen. Auf jeden Fall vielen Dank für die Erläuterungen. -- Hansm 13:45, 28 July 2009 (UTC)