Sinn und Unsinn von Relationen

Ich bitte darum, die Kirche doch im Dorf zu lassen.
Von Löschen habe ich nicht gesprochen, nur die Bitte/Hoffnung ausgedrückt, dass die Datenbank nicht mit zu vielen “losen” Sammelrelationen überladen wird. War mMn (meiner Meinung nach) nicht relativierend genug? Was drin ist, kann drin bleiben. Anlegen macht mehr Arbeit als Löschen.

Natürlich gibt es in Master-(“Sammel”-)Relationen gemeinsame Merkmale wie ref. Das ist wie erwähnt sogar ein typisches Merkmal. Ich habe selbst auch schon Fernwanderweg-Relationen (ohne Gewissensbisse) komplettiert. Wenn es gemeinsame Eigenschaften (tags) gibt, die nur in der Sammelrelation geführt werden und nicht an jedes Einzelelement geheftet werden müssen, trägt das zur Übersichtlichkeit und Wartbarkeit bei.

Was ein “enger” und was ein “loser” Zusammenhang ist, ist OSM-typisch Auslegungssache. Ich gebe nur zu Bedenken, dass es fast unzählig viele Möglichkeiten gibt, aus einer begrenzten Menge von Daten komplexere Gebilde wie “lose Sammelrelationen” zu erzeugen. Begrenzt wird das eigentlich nur von Arbeitszeit und Phantasie der Mapper.

Eine schwammige und sehr subjektive Definition wäre: Alles was man häufig als Ganzes braucht, kann in eine Relation, was man nur selten braucht in eine Filterabfrage.

Wobei jedem “Sammler” klar sein sollte, daß nur die Abfrage 100% Treffer bringt, wogegen eine Sammelrelation immer der akuraten Pflege aller Mapper bedarf.
Und das gilt sogar für diejenigen Mapper, die garnicht wissen, daß es für z.B. “Alle Hundekottütenspender in der Po-Ebene/Norditalien” :wink: überhaupt eine “Sammlung” geben könnte.

Nicht die Existenz von Sammelrelationen geht mir gegen den Strich, sondern deren prinzipielle Unzuverlässigkeit. Die paar Bytes mehr Müll in der DB machen mir da keinerlei Probleme.

Gruss
walter

Uhi… Da hab ich wohl in ein Wepennest gestochen… Das war nicht meine Absicht… :frowning:

Das mit:

hat sich ja geklärt… Redaktionsbot-Reste…

Die

: da sehe ich eigentlich eine Doppelung mit type=boundary…

Die andern vier genannten würden für mich unter die Kategorie Sammelrelation fallen, wobei gerade die letztgenannten beiden (Metrobuslinien und Nachtbuslinien) sicher recht leicht über den Tag network=xy an der Linie selbst abfragen lassen. Dazu sind meiner Ansicht nach die Tags da.

Ohne eine Abfrage gemacht zu haben, vermute ich mal, daß eh nicht alle erfassen Nachtbuslinien Berlins in der entsprechenden Sammelrelation sind.

Gerade im Kontext der Sammelrelationen würde ich aber von einem vorschnellen Löschen abraten. Stattdessen lieber einmal mehr disskutieren und beim Mapper Überzeugungsarbeit leisten, wie es besser geht, vor allem in Hinblick auf Nutzung der vorhandenen Tags und der eleganten Abfragemöglichkeiten (overpass). Das war auch eigentlich der Gedankengang meines Beitrags.

Das andere was mir eben auch auffiel, waren vereinzelte Relationen mit nur einem Element, deren Sinn sich mir nicht erschließt und ich es für richtig halte, solche in einschlägigen QS-Tool (v.a. OSMI) entsprechend zu markieren.

Grundsätzlich halte ich Relationen für eine feine Sache. Gegebenenfalls soll, kann und muß man auch den Weg mit Master- und Slave-Relatinen gehen, vgl. http://forum.openstreetmap.org/viewtopic.php?id=23731. Bei Bundesstraßen ist es z.B. allein schon aus dem Grund nötig, mindestend nach Bundesland aufzuteilen, da eigentlich die Landesstraßenbauämter den Straßenunterhalt machen (also operator=xy) und zum Netzwerk der Bundesstraßen gehören (network=xy). Ähnlich verhält es sich z.B. mit den Wanderwegen. Diese sind weitestgehend nur über Relationen abbildbar.

Ich hoffe ein wenig Ruhe hinein gebracht zu haben.

Sven

@walter

ich glaube vielen sammlern geht es gar nicht darum, alle treffer zu haben, sondern nur ihre, oder die eines bestimmten gebietes…

aber du mußt die relation ja nicht bedienen, für dich ist sie unzuverlässig, also nimmst du die overpass und fertig ist.

vieleicht sollte noch bedacht werden, das die meißten mapper weder im forum,
noch in der ml und wenig im wiki lesen, nicht jeder ist also auf neusten osm stand.

@sven

ich bin ganz ruhig :slight_smile:
ich gebe zu, der thread ist ein wenig gekappert, doch es ging irgendwie in die richtung…

grüße von lutz

Da fällt mir eine Gemeinde als Insel ein: admin-Grenze nur als Relation vernünftig erfassbar, enthält aber nur einen Linienzug (das Ufer).

Bei landuse aber (dort dürften solche Konstrukte am häufigsten vorkommen) sind ein-Elemente-MPs (MP: Monopolygon?) mE völlig entbehrlich.

Ich habe prinzipiell keine Scheu davor, in “fremden” Gebieten (Hoheitszonen wäre ja wohl etwas überheblich), neue Objekte beliebiger Art einzutragen. Nur darf dort niemand von mir erwarten, daß ich dann “seine” Sammelrelation pflege. Und schon ist diese ungenau. That’s the Problem :wink:

Ich nehme zwar meine Datenbank aber prinzipiell hast du recht. Es halt nur der “Sammler” der Gelackmeierte.

Ich auch, ICH REG MICH NICHT AUF!! ICH??? NIE!!! :wink:

Gruß
walter

So bald du das Problem mit Enklaven und Exklaven gelöst hast, kann man vielleicht auch auf MP verzichten.

So lange OSM auf Vektordaten beruht und Objekte wie “Haus mit Innenhof” abgebildet werden sollen, wird man die nur in Aggregaten bestehend aus zwei Linienzügen unterbringen können, egal wie sie heißen.
Mit einem Flächentyp, der durch die Außenlinie definiert wäre, sauberen Überdeckungsregeln von z.B. Innenhoffläche zu Gebäudefläche könnte man vielleicht auf solche MPs verzichten, aber den sehe ich in OSM noch lange nicht.

Ob man gezwungen ist, den ganzen Schwarzwald oder Harz in einem einzigen Multipolygon landuse=forest mit zig outer und hunderten inner zu erfassen (ganz so wild ist es noch nicht), ist eine ganz andere Frage.
Mein Ansatz ist: So klein wie möglich, so groß wie nötig.

Leider nicht. Die relation enthält Verbindungspunkte (aber nicht alle) von railway=light_rail. Einige (aber nicht alle) haben auch ein ref=. Habs mal rausgesucht

Da bin ich gespannt, wie du 5-6 verschiedene Wanderwege auf einem realen Weg abbilden möchtest: Beispiel

Deswegen entsorge ich nur Sammelrelationen, die ich auch als Abfrage abbilden kann und schreibe dann entsprechende Changesets (auch wenn das deiner Meinung nach nichts hilft): http://www.osm.org/changeset/20359964

Wenn ich so eine Relation zeitnah zur Erstellung finde und der User ein Neuling ist (wenig Edits), gibt es auch eine entsprechende Nachricht.

Was stört dich, wenn es weniger Datenleichen in OSM gibt? Im schlimmsten Fall dienen sie als schlechtes Beispiel für die nächsten Anfänger.
Zudem verursachen die Relationen (wie andernorts genügend dargelegt) bei Aufruf und Verarbeitung mehr Last als Nodes und Ways zusammen. Warum soll man dies für “Blödsinn”, wie du es selbst nennst, in Kauf nehmen?
Stell dir mal vor, es räumt keiner dieses Zeug auf. Wie sähe wohl OSM nach einigen Jahren aus, wenn man jedem Mapper seinen Spaß lässt? Wenn man Nodes und Wege ohne Tags findet, kann man die sicher auch liegen lassen: wird ja nicht gerendert, stört ja keinen.

Also sinngemäss eine Relation “Alle Sitzbänke in München”, bei der die Sitzbänke maximal mit ref=* getaggt sind. Lösung: Bei allen Objekten der Relation überprüfen ob es tatsächlich Sitzbänke (bzw hier: Weichen) sind und umtaggen (und vielleicht bei der Gelegenheit gleich an die Weichenspitze verschieben).

Oh doch…

Nahmd,

+1

Mehrfachzugehörigkeiten lassen sich mit der bewährten “;”-Schreibweise beschreiben.

Im gleichen Aufwasch sollten wir aber auch Kreis-, Land-, und Bundesstraßen, Straba und Buslinien usw. bearbeiten: die Relationszugehörigkeit ins Ref (so dort noch nicht vorhanden) übernehmen und die Relationen löschen. Völlig überflüssig. Die Reihenfolge der Abschnitte, die hier wiederholt als Grund für den Erhalt angegeben wurde, wird ohnehin beim Editieren immer wieder zerstört.

Letztendlich geht es uns allen doch um Verringerung der Datenmenge und des Einpflegeaufwandes. Nach meiner Erfahrung stellen Relationen das geringste Problem dar; den Aufwand macht die schiere Datenmenge. Und da sollten wir ansetzen.

Nehmen wir als einfaches für jeden nachvollziehbares Beispiel das Gebäude-Attribut “addr:street” mit seinem oft langen Attribut. Dieses harmlos aussehende Tag liefert einen signifikanten Beitrag zur Datenmenge. Und es ist in fast allen Fällen überflüssig: die zugehörige Straße lässt sich durch eine triviale spatiale Abfrage feststellen. Bis auf seltene Ausnahmen lassen sich auch Gebäude an Kreuzungen eindeutig zuordnen, über eine spatiale Abfrage, die auch die Nummern von Nachbargebäuden berücksichtigt.

Im gleichen Aufwasch können wir “addr:postcode”, “addr:city” und das so überflüssige wie nur etwas überflüssig sein kann und unsägliche “addr:country” vom Building an den Highway umhängen. Statt -zig Gebäuden die Daten an einem Highway-Segment: so reduziert man die Datenmenge. :sunglasses:

Schon diese kleine Änderung im Tagging reduzierte die Datenmenge signifikant. Euch fallen sicherlich Taggingschemen ein mit einer erheblich höheren Sparwirkung.

BTW: Ich hatte eigentlich vor, morgen zwei Wanderwege zu komplettieren. Dazu muss ich aber raus, das Wetter ist nicht gar so gut, und außerdem sind ja Los Wochos, die Löschwochen bei OSM. Dazu möchte auch ich gerne etwas beitragen. Ich hatte überlegt, die Postleitzahlbereichs-Relationen zu löschen: die sind überflüssig, weil man sie jederzeit leicht durch Abfrage der Gebäude (nach meinem obigen Vorschlag: Straßen) und geschickte Bildung einer Hülle nachbilden kann. Dem widersprach aber ein Mitstreiter heftigst: er brauche die Postleitzahl-Relationen, um seine Sammelrelationen ohne großen Aufwand postalisch sortieren zu können. So ein Mist! Denn mir fällt auf die Schnelle nichts anderes ein; ihr habt ihr euch ja alle guten Sachen schon untern Nagel gerissen. Ist denn nicht noch irgendwas übrig für mich zum Löschen?

Weil wenn nicht, wäre das blöde: dann müsste ich nämlich wirklich raus ins Gelände. :confused:

Gruß Wolf

Keine Sorge, mit dem Löschen deiner Stolpersteinkarte bist du gut dabei.
(Mir fällt wiederum auf, dass du keine sachlichen Argumente bringst, sondern nur Polemik.)

die ist nicht gelöscht, sondern umgezogen:

http://geschichtskarten.openstreetmap.de/stolpersteine/

grüße von lutz

Nunja. Bei Polemik “ohne” sachlichen Argumenten haben die Diskutanten den Vorteil, dass sie zwischen den Zeilen lesen könn(t)en.
Bei Löschungen ohne Not - finde die Passage gerade nicht - sieht es etwas anders aus - sinngemäss meinte jemand was von Krümelkackerei oder so ähnlich dazu. Unterschreibe ich.

Vielleicht was konstruktives dazu:
Erstmal meine Meinung im Klartext: Ich halte das Löschen von egal welchen Informationen für kontraproduktiv. Jeder soll (ok, in gewissen Rahmen) mappen, was er will. Ich persönlich finde es bspw. reichlich daneben Aufback- oder Fliessbandbrötchenverkäufer mit shop=bakery (etc.) zu adeln, ich käme im Traum nicht drauf, da irgendeine Initiative dazu zu starten. OSM ist voll davon. Ich mappe sowas einfach nicht. Fertig.
Genauso sehe ich das bei Relationen. Eine Relation, die kaputt ist oder mich nicht interessiert oder die mit irgendeinem utopischen Tool zu rendern wäre, mache ich entweder ganz oder nicht. Fertig.

Ich halte auch das Overpass-“argument” für Quatsch. Auf Openstreetmap(.org) gibt es kein Overpass, und ich bin überzeugt, dass die meisten, die etwas suchen, das auf “unserer” org suchen und nicht bei irgendeinem von tausenden OSM-Abkömmlingen. Das ist jetzt kein überzeugendes valides Argument für Nonsens-relationen aber imho gegen Löschungen von grenzwertigen.

Ich persönlich bin betroffen vom Löschen der Stolpersteinrelation(en). Ich habe da in meiner Stadt sehr viel Zeit investiert mich mit der Funktionsweise von Relationen vertraut zu machen und plötzlich fliegen da Stunden meiner Arbeit raus, weil es von einer handvoll Leute auf irgendeiner mir nicht bekannten Mailingliste besprochen wurde. Dass an dieser (und anderer) Relation ein paar Hundert Leute hart gearbeitet haben und ihr Herzblut investiert haben, das steht dann lapidar an einem Changeset.

Fazit: Welche Relationen darf ich in Zukunft noch anfassen?

Sorry, aber vielleicht hast du das Argument übersehen. Es ist in meinen Augen ganz entscheidend. Wo ist die Grenze? Was ist noch sinnvoll als Relation und wann ist es nicht mehr sinnvoll.
Er drückt sich an der Stelle vielleicht nicht besonders gut aus, aber er versucht zu ergründen warum diese und jene Informationen in OSM überflüssig sind und bietet an diese als virtuelle Relationen über Abfragen zu ersetzen.
Was daran Polemik ist müsstest du schon einmal mitteilen. Oder stehen Daten wie addr:city unter Denkmalschutz und sind daher nicht vergleichbar?

Man kann Recht haben und trotzdem polemisch sein. :slight_smile: Und ich denke, das war durchaus seine Absicht.

Bei addr:country|city|postcode bin ich sogar fast einer Meinung. Relationen/Polygone mit spatialer Abfrage sind da viel datensparender, zuverlässiger, pflegeleichter.
Die Infos stattdessen an die Straße zu pappen, ist hingegen einen Schritt zu kurz gedacht.

Ich würde auch mal gerne die “triviale” spatiale Abfrage sehen, die mir zuverlässig sagt zu welcher Straße jedes Haus gehört.

Freunde, das ist keine Polemik, sondern Satire. Oder ist euer Ironiedetektor kaputt?

Müssen wir uns Gedanken machen um die Datenmenge? Wird die Datenmenge durch schieres löschen nicht gar größer?
Ich würde mich eher wambachers Meinung anschließen. Wer alles aktuell haben will, soll seine Sammelanfragen durch Abfragen lösen. Für diejenigen denen das nicht möglich ist gibt es immer noch die Option unvollständige Daten auf dem bisherigen Weg zu erhalten.

1+ du hast es erfaßt.

Gruss
walter

Wir müssen uns Gedanken machen, wenn die Datenmenge negativ mit der Datenqualität korreliert.
Wir sollten bzgl. Abfragen und Relationen nicht alle Daten in einen Topf werfen. Klingt es für Dich sinnvoller, bei der Änderungen einer PLZ oder eines Gemeindenamens alle (sprich tausende) addr-Tags ändern zu müssen, damit Sammelanfragen (oder auch Einzelabfragen) auch das richtige Ergebnis liefern?