Tagdesign: Kombinierbarkeit, Parsebarkeit und Objektabstraktion

[Fabi2 (Fabian)]

Oder anders gefragt, was können die Editoren, etc. noch vernüftig parsen?

Es ist nämlich sehr schwer leichte Parsebarkeit (Programmen wird im Zweifelsfall immer genau gesagt wonach sie suchen müssen) mit Allgemeingültigkeit (der Tag kann auch für sich alleine stehen), sowie die richtige Abblidung der Abstraktionsebenen (wenn der Tag in eine sehr spezifissche Unterkategorie fällt, sollte man auch einen Treffer bekommen, wenn man nach der Überkategorie des Tags sucht) unter einen Hut zu bekommen, wie ich gerade feststelle.

Leider finde ich da keine Empfehlungen oder Hinweise dazu.

Ich arbeite ja gerade an Healthcare 2.0, hier mal ein Konkretes Beispiel dazu:

Will man maximale Kombinierbarkeit der Tags, macht man spezifische Tags wie:

health_care:person:physician=yes

das läßt sich dann leicht mit

health_care:person:therapist=yes

kombinieren, weil es gibt ja z.B. Psychiater, die sind gleichzeitig noch Psychotherapeut.

Da ist nur die Frage, ist die Software schnell in der Lage, vernüftig herauszufinden, nach welchem Objekttyp, in diesem Falll “person” sie zu suchen hat?
Aus meiner Sicht nein, weil da muß man eine Substringsuche für alle Keys machen um den Objekttyp zu finden! Andererseits empfehlen Leute, auch zu recht, daß man überflüssige Redundanzen und Hilfstags zur Abbildung der Taghierarchie, die ohne wirklichen Mehrwert für den Menschen sind, nicht benutzen sollte, was ja an sich auch berechtigt ist. Weil mit dem Hilfstag

health_care=person

Weis die Software sofort wonach zu suchen ist, nur hat der Tag keinen informationellen Mehrwert, da die information ja auch schon im spezifischeren Subtag health_care:person:*=yes steht. Soll man so etwas trotzdem benutzen, auch wenn der die Mapper da im Editor mehr schreiben müssen, damit die Software nicht per Substringsuche alle möglichen Werte für die Subkeys ausprobieren muß in der Hoffnung etwas passendes zu finden? Aus meiner bisherigen Sicht denke ich da ja.

Das Problem was mit der tollen Kombinierbarkeit der binären (*=yes/no) Tags einher geht, ist neben dem Vergeuden von Rechenzeit für die Substringsuche (das wird bei mehreren Namespaces dann erst richtig lustig!), auch das die Objektbeziehungen unter Umständen nur unzureichend wiedergegeben werden.

Beispiel: Jemand definiert:

health_care:speciality=haste_nicht_gesehen_surgery=yes

Um der allgemeinen Kombinierbarkeit zu entsprechen, definiert man nur health_care:speciality=* obwohl das ja klar eine health_care:subspeciality=* ist, nämlich von health_care:speciality:surgery=yes bzw. um das Substringdurchduchproblem zu umgehen und dafür die freie Kombinierbarkeit einzubüßen, mit health_care:speciality=surgery. Mit Relationen ist das ja keine Problem, da amcht man notfalls mehre, aber wie löst man so etwas für normale Knoten/Wege/Flächen? Weil bei mehrenen Fachgebieten in health_care:speciality=* geht da dann ja wieder das Substringsuchproblem los, auch wenn man die Tags alphabetisch sortiert, ist das nicht wirklich eine Lösung.

Außerdem sieht jemand health_care:speciality=haste_nicht_gesehen_surgery=yes ja vielleicht zu recht als völlig ausreichend an, aber die Anwendung möchte dann vielleicht alle Chirurgen haben und sucht nach health_care:speciality:surgery=yes, ohne dafür wisslen zu müssen, welche noch so kleinen Fachunterscheidungen da gemacht werden. Das spricht dafür auch health_care:speciality:surgery=yes definieren zu müssen, nur damit man das auch findet, wenn man nach der übergeordneten Abstraktionsebene sucht, mal abegesehn davon, das Abstraktionsebenenbezug dabei verloren geht.

Hat jemand da Ideen oder Hinweis wie man so etwas sinnvoll für Nicht-Relationen lösen kann?
Namespaces im Key bzw. mehrere Werte im Value sind imho nur gut für den Menschen, aber nicht für die Software, die die Daten auswerten soll.

[_i]

Ich habe leider keine Idee, aber vielleicht findest du in den Seiten von http://wiki.openstreetmap.org/wiki/Category:Tagging_guidelines ja etwas?

Generell finde ich deine Überlegungen aus meiner Sicht als Programmierer sehr gut . Nur werden die Daten von Menschen eingetragen und sollten auch ohne einen Editor konsistent und schnell eingegeben werden können. Das sehe ich bei 2 Namespaces nicht mehr

Etwas offtopic aber man sollte auch bedenken, dass die Details, die du mit solchen komplexen Schemas erfassen willst irgendwie aktuell gehalten werden sollten. Das sehe ich bei so einer Feinkörnigkeit einfach nicht (genauso wie ob ein Telefon Karten oder Münzen annimmt, die Farbe einer Bank,…). Klar gibt es Szenarios, wo es sehr schön ist diese Infos zu haben (z.B. Erzeugen eines 3D Modells) aber die sollten ja dann trotzdem auch stimmen. Ich befürchte du machst dir da Gedanken, die letzten Endes zwar ein konsistentes Datenmodell bieten, das aber eigentlich garnicht ausgenutzt wird

[Fabi2 (Fabian)]

@!i!

Ich habe leider keine Idee, aber vielleicht findest du in den Seiten von http://wiki.openstreetmap.org/wiki/Category:Tagging_guidelines ja etwas?

Generell finde ich deine Überlegungen aus meiner Sicht als Programmierer sehr gut . Nur werden die Daten von Menschen eingetragen und sollten auch ohne einen Editor konsistent und schnell eingegeben werden können. Das sehe ich bei 2 Namespaces nicht mehr

Naja, das war ja mein bsiheriger Ansatz, also mit Hilfstag für health_care=* und dann schreibe ich eben für Nodes/Ways/Areas maximal einen Tag vor, damit das ganze vernüftig parsebar ist und die Hierachie trotzdem vernüftig abgebildet werden kann. So nach dem Prinzip: Wer mer möchte muß Relationen benutzen, da kann man für den Foktor dann 20 Kindrelationen für seine ganzen Fachgebiete erstellen.

@!i!

Etwas offtopic aber man sollte auch bedenken, dass die Details, die du mit solchen komplexen Schemas erfassen willst irgendwie aktuell gehalten werden sollten. Das sehe ich bei so einer Feinkörnigkeit einfach nicht (genauso wie ob ein Telefon Karten oder Münzen annimmt, die Farbe einer Bank,…). Klar gibt es Szenarios, wo es sehr schön ist diese Infos zu haben (z.B. Erzeugen eines 3D Modells) aber die sollten ja dann trotzdem auch stimmen. Ich befürchte du machst dir da Gedanken, die letzten Endes zwar ein konsistentes Datenmodell bieten, das aber eigentlich garnicht ausgenutzt wird

Ja, das Argument habe ich schon öfter gehört, ich bin schon sehr dafür das Schema flexibel/erweiterbar zu halten und auch alles Notwenige auch erfassen zu können. Im Moment ist healthcare 2.0 nicht sehr detailiert, sondern bildet aus meiner Sicht mehr die Realität ab. Weil wenn ich in einem Ärztehaus mangels Plan oder Empfangs schon nicht die Praxen der Ärzte mappen kann, dann will ich wenigstens noch die Personen die dort arbeiten, dem Haus zuordnen können. Ehere kann man ja an meinem Schema kritisieren, das man person=* und facility=* auch gleich allgemein definieren könnte, damit in arnenity=’ mal aufgeräumt werden kann, aber da sit leider das Problem, daß service=* schon vergeben ist und das Taggingschema von den Keys her konsitent sein und für sich selbst sprechen soll.

Wegen dem Detailierungsgrad der Objekte: im Grunde ist es egal, ob ich eine Sammlung von Straßen und Wegen mit ihren Oberfächenbeschaffenheiten, Geschwindigkeitsbeschränkungen und Durchfahrverboten aktuell halten muß oder eine von z.B. Treppen mit Stufenanzahl, Stufenbreite und -höhe. Der Aufwand ist der gleiche, es kommt nur darauf an, worauf die Mapper jeweils ihr Hauptaugenmerk richten.

[_i]

Hmm ja ok das ist dein Fokus Fabi. Aber du möchtest ja, dass das 100te von Mappern nutzen? Und ähhh ich glaube die machen sich da nicht so den Plan
Ein guter nächster Schritt wäre doch auch erstmal, die Einrichtungen zu erfassen. Vielleicht nicht perfekt aber sie wären erstmal drin, werden vielleicht gerendert und dann entsteht vielleicht auch der Wunsch der User mehr Details dazu zu erfassen. Dann könnte man die Orte direkt ansteuern und die Eigenschaften bestimmen und man hat bereits Erfahrungen mit dem alten Modell gesammelt.

Versteh mich nicht falsch, prinzipiell bin ich auch jemand, der Sachen gerne ausformuliert und 100%ig macht. Nur habe ich gemerkt, dass es so nicht bei OSM funktioniert. Es muss so auch garnicht funktionieren, dass macht nichts. Immer Schritt für Schritt

[Fabi2 (Fabian)]

@!i!

Hmm ja ok das ist dein Fokus Fabi. Aber du möchtest ja, dass das 100te von Mappern nutzen? Und ähhh ich glaube die machen sich da nicht so den Plan
Ein guter nächster Schritt wäre doch auch erstmal, die Einrichtungen zu erfassen. Vielleicht nicht perfekt aber sie wären erstmal drin, werden vielleicht gerendert und dann entsteht vielleicht auch der Wunsch der User mehr Details dazu zu erfassen. Dann könnte man die Orte direkt ansteuern und die Eigenschaften bestimmen und man hat bereits Erfahrungen mit dem alten Modell gesammelt.

Versteh mich nicht falsch, prinzipiell bin ich auch jemand, der Sachen gerne ausformuliert und 100%ig macht. Nur habe ich gemerkt, dass es so nicht bei OSM funktioniert. Es muss so auch garnicht funktionieren, dass macht nichts. Immer Schritt für Schritt

Aber das ergebnis davon ist, daß das Rad x mal neu erfunden wird, weil jeder aus seinem Blickwinkel meint, den Tag auch definieren zu müssen. Weil wo kommen wir den da hin, wenn man z.B. nicht mehr die Wahl zwischen emergency_service=ambulance und emergency=ambulance_station hat. Dann definiert sich jeder noch seinen Tag für ein Krankenhaus wie amenity=hospital, health_facility:type=hospital oder healthcare=hospital und wenn das dann mal jemand integrieren möchte, ruft man ganz laut, daß die Tags ja alle schon etabliert sind und man das auf gar keinen Fall ändern dürfe.

[Geogast]

@!i!

Etwas offtopic aber man sollte auch bedenken, dass die Details, die du mit solchen komplexen Schemas erfassen willst irgendwie aktuell gehalten werden sollten. Das sehe ich bei so einer Feinkörnigkeit einfach nicht (genauso wie ob ein Telefon Karten oder Münzen annimmt, die Farbe einer Bank,…). Klar gibt es Szenarios, wo es sehr schön ist diese Infos zu haben (z.B. Erzeugen eines 3D Modells) aber die sollten ja dann trotzdem auch stimmen. Ich befürchte du machst dir da Gedanken, die letzten Endes zwar ein konsistentes Datenmodell bieten, das aber eigentlich garnicht ausgenutzt wird

Die Befürchtung teile ich. Die Entwicklung bei OSM geht ja im Moment zu einer extremen Verfeinerung des Taggings (zB hier zu Möbelhäusern).
Aber wenn ich mir anschaue, wie lange manche wirklich sinnvollen OSBugs offen bleiben oder wie viele wesentlichen POIs in meiner Heimatstadt nicht gemappt sind, dann frage ich mich, wer solche hoch spezialisierten Geschichten wie hier eigentlich pflegen will.

[Fabi2 (Fabian)]

@Geogast

Die Befürchtung teile ich. Die Entwicklung bei OSM geht ja im Moment zu einer extremen Verfeinerung des Taggings (zB hier zu Möbelhäusern).
Aber wenn ich mir anschaue, wie lange manche wirklich sinnvollen OSBugs offen bleiben oder wie viele wesentlichen POIs in meiner Heimatstadt nicht gemappt sind, dann frage ich mich, wer solche hoch spezialisierten Geschichten wie hier eigentlich pflegen will.

Das mit den ungemappten POIs selbst in Studenten- (in der Greifswalder Innenstadt z.B. gibt es noch diverse Läden in mindestens zwei dicht besetzten Ladenstraßen und nicht nur die paar Cafes und Kneipen) und Großstädten (selbst kleine Knotenpunkte wie den Bahnhof Berlin Lichtenberg mußte ich erst mal rudimentär mit ein paar POIs versorgen, aber vielleicht lag es auch in Berlin daran, das ein großer Teil davon nicht von Mapnik gerendert wurde/wird) stimmt, da habe ich auch selbst schon diverse Gebiete gemappt.
Aus meiner Sicht ich es wichtig, das es zumindest Tags für alles gibt, weil eingetragen von der ganzen Auswahl wird eh nur das was die jeweiligen Mapper für wichtig ansehen, da ist es eben, wie ich ja schon schrieb, im Endeffekt egal. Es gibt ja eh eine Grenze in Gezug auf die Praktikabilität der Erfassung, z.B. werden die wenigsten Leute immer mit Winkelmesser und Zollstzock Bordsteinhöhen und Rampenneigungen für die Rollstuhroutingkarten messen können, wenn sie raus mappen gehen. Das Gleiche gilt für Treppen, bestenfalls erfaßt man da noch die Stufenzahl als Zusatzattribut, aber es ist vorteilhaft, daß wenn man sehr detailierte Daten hat oder wenn man möchte, mehr Objekteiigenschaften erfassen kann.