Don’t repeat yourself

Eine Frage die mir mal wieder durch den Kopf ging: würde es irgendwie gehen, dass man die OSM-Datenbank so aufbaut, dass man sich bei gleichen Dingen nicht wiederholen muss (Don’t repeat yourself). Aufgefallen ist mir das beim Thema zum KFC. Wenn man die Daten nur einmal in der Datenbank hätte, dann würde man sich fehleranfällige Redundanz sparen. Man hat also einen einzigen Datenbank-Eintrag zu KFC und auf diesen verweist man dann quasi von den unterschiedlichen Restaurants. Das natürlich nicht nur für Fast-Food-Restaurants sondern auch für andere Dinge. Wäre so ein Prinzip für OSM umsetzbar? Wie könnte das aussehen?

Mit einer Relation ginge das.

Allerdings sind wir dann gefährlich Nahe am Thema Sammelrelation. :smiley:

Sehr schwierig. Wie sollte ein Anfänger wissen, ob es das Element schon gibt? Und wenn ein Teil einer Ladenkette den Namen ändert, dann hat man als Anfänger schnell weltweit den Namen geändert, weil man sich der Tragweite oft nicht bewusst ist. Wir müssen da doch mehr auf das KISS-Prinzip setzen.

Wie Chris schon andeutete: Datenbanken können das und es ist sogar Usus, häufig wiederkehrende Begiffe in eigene Tabellen zu legen und nur einen Verweis drauf zu setzen.
Allerdings passt das (leider) überhaupt nicht in das bestehen DB-Schema von Osm.

Gruss
walter

Fremdschlüssel auf Objekte ohne Geobezug.
Diese als Feldwert erlauben.

Was für
http://wiki.openstreetmap.org/wiki/API_v0.7 ?

Würde eventuell auch helfen diese Schlammschlachten um Sammelrelationen einzudämmen.

Christoph

Redundanzen sind nicht perse schlecht! Es gibt nämlich immer Fälle wo man darüber auch Fehler finden kann. Siehe nur die lustigen Postleitzahlen in Deutschland.
Außerdem haben Datenbanken welche das von dir betriebene normalisieren betreiben andere Probleme. Zu allererst mit der Performance. Denn statt die Objekte einer Tabelle abzufragen müssen jetzt Joins aus zwei Tabellen erstellt werden, die je nach Komplexheit dann ein vielfaches der Ursprungsdaten ergeben. Das Ganze ist wahrscheinlich auch kein Problem, so lange man verteilte Datenbankserver nur für die Abfrage betreiben kann. OSM hat aber einen Server, welcher alle Einträge speichern muß und nebenbei noch die Anfragen der meisten Editoren bedient.
Als nächstes ungelöstest Problem ist dann die Frage was ist der Schlüssel. Heute steht OSM auf dem Standpunkt das die XML Daten menschenlesbar sein sollen. Daher wären kryptische Schlüssel eher unerwünscht. Das scheint auch das Hauptproblem bei dem OSM 3d von Mareks Dachformen zu sein.
Und zu guterletzt kommt dann das Problem das es für eine breite Akzeptanz auch schnell erfassbar sein muss. Siehe ÖPNV.

Ja, das Problem ist natürlich, dass dies OSM ja auch nicht komplizierter machen sollte. Eine externe Datenbank auf die man irgendwie verweisen kann bzw. auf die man automatisch mit einem bestimmten Wert verweist (z.B. dem name-Tag) halte ich vielleicht noch für am vernünftigsten. Evtl. könnte so was dann auch gleich zur Qualitätssicherung beitragen wenn man damit automatisch bestimmte Objektarten auslesen und in die DB eintragen lässt (bspw. vorhandene Tankstellen einer bestimmten Kette) und dann mit einem eingetragenen Soll-Wert vergleicht. So könnte man schnell erkennen, was und wie viele noch fehlen. Dazu kann ich dann noch sagen, dass ich es ja zwar schön finde, wenn solche Vergleiche immer mal wieder von kompetenten Leuten gibt, die schauen was der Ist-Wert ist und mit einem Soll-Wert vergleichen. Aber so etwas müsste auch für Laien möglich sein und für mehr Objekte. Vielleicht wäre das auch was im Zusammenhang mit der Wikipedia-Datenbank Wikidata?

Und vielleicht kannst du, TheFive, das ja so wie du es für geschickt hältst in diese API-Wunschliste eintragen? Wäre sehr schön.

Und danke für die Antwortenden.

Repeat yourself most perfect!

Wird in Vespucci “MC” als Name eingegeben so erscheint McDonald’s. Wird das ausgewählt, so wird der POI um amenity=fast_food, cuisine=burger ergänzt.
Das kann man mit einer Art Volltextsuche noch erweitern. Dann dazu noch ein passendes Formular mit weiteren Schlüsse - wie in JOSM. Für den Anfang ausreichend.

Stehen die Dinge in einer separaten Tabelle und sind nur über Schlüssel gekoppelt, so ist die OSM-DB ohne die separate Tabelle wertlos.
Botläufe werden in OSM kritisch gesehen, weill der Bot vielleicht zu 99% richtig arbeitet aber in 1% der Fälle falsch.
Ändert man den Eintrag in der Refernztabelle, auf den sich 1000 Einträge beziehen, so hat man damit “tausend Änderungen” gemacht. Uiuiui…
Geht nur Problemlos wenn man Einträge in der Referenztabellen als in Steingemeisselt betrachtet.

Eine Vorlagen/Template-Datenbank inklusive Formularen (wiederum mit Vorschlägen zu den Feldern) wäre eine einfache Lösung. Eine Repeat yourself most perfect!

Vielleicht auf der Basis einer separaten SQLite-Datenbank die unabhängig von OSM-Entwicklungswerkzeugen gepflegt wird.
SQLite… da das auch auf jedem Mobiltelefon läuft.

Prima Idee!
Jetzt können wir endlich die OSM-DB so eindampfen, dass sie sogar auf der Apple Watch und dem RasPi läuft: nur noch je eine Verwendung eines jeden key=value-Paares – und OSM passt auf ein A4-Blatt!1


Dieser Beitrag kann Spuren von Ironie enthalten.

Dieser Beitrag war sinnfrei und nicht ironisch. Denn es ging dem Ersteller vorallem auch darum Gleiches gleich zu benennen. Außerdem, so seine Hoffnung, wenn die Information nur an einer Stelle steht, lassen sich Fehler besser vermeiden. Siehe Wikidata, welche für die Wikipedia ein ähnliches Konzept verfolgt.

Eigentlich kann Josm das schon. Er baut sich ja eine lokale Liste aller verwendeten Tags auf und verwendet diese um beim Erfassen neuer Daten Vorschläge zu machen. Nur halt lokal nur für das aktuelle Gebiet.
Er könnte sich beim Start auch so eine Liste vom Osm-Server holen und die benutzen. Und diese in den Cache legen, damit es beim nächsten mal schneller geht.

Gruss
walter

Es ist aber wohl so das diese Liste gepflegt werden muss. Josm macht beim lokalen Erstellen der Liste nämlich keinen Bogen um falsche Schreibweisen oder veraltete Tags. Der Lokale Bezug hat außerdem den Vorteil, dass man sich den lokalen Gegebenheiten anpasst. Es wird ja nicht in allen Teilen der Welt alles gleich gemacht.
Und das was EinKonstanzer beschrieben hat ist eigentlich nicht eine Autovervollständigung wie bei Josm sondern eher eine Autokorektur wie bei Andorid. Da wird dann unterstellt das MC immer für Mc Donalds steht und nicht für etwas anderes.

Kurz zur Erklärung: Vespucci braucht https://github.com/osmlab/name-suggestion-index um vom Namen auf die Basistags zu kommen. Wenn man will kann man auch gerade das bestpassende Preset anwenden lassen um noch weitere Tags zu bekommen.

Simon