Ich bin ehrlich, ich habe ja auch schon eine kleinere be-/genutzt: Abbiegebeschränkungen. Destination_sign hatte mir bis gerade eben nichts gesagt, klingt aber auch interessant. Alles was zu ÖPNV gehört bin ich grad dabei mich einzulesen. Auch Site-Relationen (https://wiki.openstreetmap.org/wiki/Relations/Proposed/Site) habe ich mir angeschaut, aber das Beispiel mit der Schule (Sangster Elementary School in Springfield) - ich hätte genau so einen Fall, deswegen bin ich durch eine Suche dort aufgeschlagen - ist mittlerweile veraltet oder? Zumindest finde ich dort und auch wenn ich die einzelnen Elemente anklicke keinen Verweis auf MemberOf-irgendeiner-Relation?!
Off topic:
Keine Sorge, ich bin Fachinformatiker, ich komme gar nicht ohne Relationen aus, wobei ich mittlerweile gerne auch Graphen verwende
Oder auch keines von beiden. Zu OSM bin ich über udacity und einem mongoDB-LearningProject gekommen.
Relationen an sich sind nichts “Schlimmes”. Mit ein wenig Geschick und einem vernünftigen Editor (Josm) kommt man leicht in die Materie rein.
associatedStreet hat wie auch die Sammelrelationen den Nachteil, daß es keinen Automatismus gibt, die einen daran erinnert, auch wirklich alle Neuzugänge dort einzufügen. Der eine Mapper erfaßt einige Hausnummern und trägt sie auch dort ein; der andere bemerkt noch nicht einmal, daß es solch eine Rel gibt und trägt die Hausnummern natürlich dort nicht ein. Und das war es dann mit dem Sinn dieser Rel.
Ähnliche haben wir ja auch bei den Stolpersteinen, bei denen das Thema anscheinend auch wieder hochkocht.
OSM ist immer von Kompromissen geprägt und das wird wohl immer so bleiben müssen, da die reale Welt abgebildet wird und nicht ein theoretisches Gebilde.
addr:street ist (neben der Hausnummer) übrigens der Bestandteil der Adresse, der am wenigsten redundant ist, da er wie richtig bemerkt oft nicht aus der nächsten Straße abgeleitet werden kann.
Die anderen Bestandteile der Adresse von city bis country sind redundant in dem Sinn, dass diese Informationen auch aus anderen Objekten (sprich Grenzen) hergeleitet werden können. Trotzdem fügt man sie aus pragmatischen Gründen gerne ein, da dann alle wesentlichen Information “auf einen Klick” zur Verfügung stehen. Dass dann gelegentlich die quasi redundanten Informationen nicht zusammenpassen, nimmt man in Kauf.
Relationen sind etwas schwieriger zu handhaben, weil sie naturgemäß immer mehrere Objekte enthalten (sollten). Wenn man Pech hat auch solche, die gar nicht angezeigt werden. Daher kommt es eben immer wieder vor, dass ungewollte Nebeneffekte auftreten, wenn man Mitglieder der Relation bearbeitet. Das macht sie nicht immer beliebt, aber bei vielen Sachverhalten kommt man ohne sie nicht aus. Man sollte sie aber aus diesen Gründen auch nur dort nutzen, wo es ohne sie nicht geht.
associated_street hatte seine Berechtigung zu Zeiten von Satellitenbildern mit Auflösungen im zig-Meter-Bereich. Da war man froh, wenn neben einer Straße wenigstens noch ein Hausnummernbereich eingetragen war, der dann mittels dieser Relation verknüpft wurde. Bei den heutigen Auflösungen braucht man diesen Ausweg nicht mehr zwingend, da landet die Straße am Hausumriss, einem Knoten im Gebäude oder am Eingang.
Ja, Walter, im Prinzip hast Du Recht. Ich will aber die Hoffnung an das Gute in der Informatik und dem Menschen auch in diesem Fall noch nicht ganz aufgeben.
An jede Adresse “addr:street” zu taggen ist nicht unbedingt weniger fehleranfällig (Weglassen, Schreibweise etc.). Richtig ist aber auch, dass das Karlsruhe-Schema in der Welt ist und nicht so leicht abzulösen ist.
Ich denke, dass langfristig Straßenrelationen (als Entitäten) besser wären, auch wenn ich associatedStreet wegen der verschwindend geringen Verbreitung (und des blöden Namens) nicht verwende. Sobald es Tool-Support (Editor, Auswertung) für eine Straßenrelation gibt, spricht ja auch nichts dagegen, dies in der Auswertung robust mit den “addr:street”-Fällen zu kombinieren. Ein Quasi-Automatismus könnte eine Warnung im Editor sein, wenn bei einer Adresse die Straßenentität nicht referenziert ist.
Stimmt natürlich. AssociatedStreet ist wesentlich “sauberer” als das sture Erfassen nach dem Karlsruher Schema. (war ja selber ein Fan von associatedStreet, bis ich die Probleme erkannte - und das bereits in meinem “eigenen” Dorf)
Ein Automatismus, der einen erinnert wenn eine neue Adresse nicht dort drin ist, würde schon was bringen - und es könnte sein, daß ich dann wieder das Lager wechsele.
Nicht zu vergessen die logische Relation für die Wissensrepräsentation (Mann als Vater hat Mensch als Kind; Mensch als Fahrer fährt Auto etc.).
associatedStreet scheint übrigens (nicht ganz passend) nach dieser Interpretation benannt zu sein.
So ist es. Für ein richtig schönes GIS fehlt nmM allerdings noch die (primär nicht-geometrische) Entität und echte Relationen (s.o.), um diese zu verknüpfen. Na ja, vielleicht im nächsten Open-GIS-Projekt. Wie wärs mit “OpenGIS” (Mist, hat das OGC schon als Marke registriert) und Lizenz CC0?
Korrektur: (OT!) Ein gutes GIS-Projekt bräuchte noch thematische Daten-Trennung (so ne Art Layer oder Datengruppe) und die Möglichkeit für eigene Lizenzen für jede Datengruppe.
Keine Sorge, dem bin und war ich mir schon bewusst. Wollte damit nur aussagen das man in der IT immer irgendwie mit Relationen zu tun hat, egal wie die Relation contextbezogen definiert ist… die OSM Relation könnte man, wenn man ganz (ver)quer(t) denkt fast schon als Graph sehen.
Jetzt widme ich mich erstmal den Bushaltestellen-Relationen, nachdem ich für meine Region erstmal ein paar Wiki-Seiten nachgezogen und so ganz neben QS mit den diversen Tools gemacht habe.
Aus Sicht einer Informatikerin kann ich nur sagen: Eine API zum Modifizieren von Daten sollte auch Konsistenzprüfungen durchführen und fehlerhafte Daten nicht zulassen.
Heißt: Viele Konsistenzprüfungen, die jetzt in keepright, OSMI oder JOSM sind, gehören eigentlich in die API. In einer optimalen Welt würde OSM z.B. keine sich kreuzende Straßen ohne Kreuzungs-Node zulassen, aber eben auch beim Hochladen eines neuen Gebäudes erkennen, dass es in unmittelbarer Nähe dazu bereits eine associatedStreet-Relation mit dem Straßennamen des Gebäudes gibt und einen Upload entweder blockieren, von einem zweiten Benutzer gegenprüfen lassen oder die Inkonsistenz einfach selbst beheben (durch Aufnahme des Hauses in die Relation). Leider (oder auch zum Glück, da bin ich mir nich sicher) ist das hier keine optimale Welt und wir müssen so dumme Dinge wie „Kompromisse“ und „Hacks“ in Kauf nehmen…
