[Talk-de] Re: Deutsche Attribute

Immanuel Scholz imi at eigenheimstrasse.de
Mo Aug 14 15:20:35 UTC 2006


Hi

Also ich bin Imi und gerade zu faul zum Vorstellen, also gibts nur den
Link ;-)

http://wiki.openstreetmap.org/index.php/User:Imi


>> > Sehe ich etwas anders, ich denke es macht Sinn möglichst viele
Atrribute in allen Sprachen zu benutzen, damit man Renderer nicht
immer wieder umschreiben muß.
>>
>> sicherlich eine Diskussion, die man Stunden führen kann. Ich bin halt
der Meinung, Renderer sollten aus genau diesem Grund so wenig wie
möglich Attributbezogen programmiert sein bzw. in dem Punkt am
>> leichtesten customizable.
>
> Das betrifft aber nicht nur die Renderer, sondern alles, das OSM-Daten
verwendet (z.B. um die nächsten Tankstellen zu finden).  Wenn die
Attribute übersetzt werden, landen wir noch bei einer 5M großen
> osm-tag-mapping.xml.

Der Renderer selber braucht nicht zwingend customizable sein. Er möchte
eine Sicht auf die Daten, die in seinem Lieblingsformat ist.

Genauso wollen alle anderen Tools, die Daten verwerten, die Datenformate
am liebsten in der ihnen genehmen Art und Weise präsentiert sehen.


Nun ist das Problem, dass Renderer die Daten ganz anders aufbereitet
wollen als zum Beispiel Routing Applikationen oder Statistiktools.


Das prinzipielle Problem, dass unterschiedliche Tools Daten
unterschiedlich wollen kann man auf verschiedene Weise verschieden gut
oder schlecht lösen.

1. Einführung von Namensräumen. Wenn man den tags eindeutige ID's
voranstellt, können bestimmte Programme das vorhandensein dieser
eindeutigen Tags fordern. Z.B. will dann osmarender bestimmte Dinge wie
Straßentypen immer in "osmarender:highway" sehen. Falls die Leute von
GPSDrive das dann genauso machen würden (was sie momentan nicht tun),
würden sie z.B. "gpsdrive:highway" oder "gpsdrive:type" oder was auch
immer wählen.

Vorteile:
 * Man kann es theoretisch jetzt schon benutzen. (Kein Aufwand in der
   Programmierung des Systems). Allerdings müssen dann Nutzer die Prefixe
eingeben
 * Sieht so aus, als wird sich dieser Weg ohne Überzeugungsarbeit
   etablieren (also kein Überzeugungsaufwand).

Nachteile:
 * Programmieraufwand in allen Clients um die Namensräume zu verstehen. *
Wartungsarbeit in der Datenbank (redundante Speicherung)
 * Aufwand für die Datensammler (Tags z.T. mehrfach eingeben)
 * schlechtere Dateneffizienz (mehr Tags notwendig -> größer, langsamer)


2. Design by Comitee. Man kann sich zusammensetzen und für die wichtigsten
Applikationen von OSM (auch alle zukünftigen) eine Tagstruktur definieren.
Map-features geht diesen Weg. "name" wäre dann immer der Name des Objekts,
"highway" immer und in jedem Land der Typ der Strasse und so weiter.

Vorteile:
 * Kein Programmieraufwand
 * professionelle Kartographen kennen diese Vorgehensweise

Nachteile:
 * <alle Nachteile von "design by comitee" hier einfügen> ;-)
   (glaubt mir, es WIRD eine komplexe Struktur werden...)
 * Wo ist dann noch der Unterschied zu OpenGIS? --> gleich OpenGIS nehmen.
* Risiko, eine komplexe Struktur in der Semantik der Tags zu bekommen
   (Wenn das gleich das gesetzt ist, dann wird das so interpretiert, außer
das ist das...)


3. flickr-Approach. Jeder definiert sich die Struktur nach einer
unspezifizierten "Vernunft". Für größere Andwendungen gibt es dann
Proxies, die Daten entsprechend formatieren und in eine definierte
Datenstruktur pressen (z.B. GPSDrive macht dies). Einige Anwendungen
können mit einer "Unschärfe" auch leben.

Vorteile:
 * Erprobt. Hat sich bei vielen neueren Internetanwendungen bewährt *
Ideal auch als initialer Weg um passende Strukturen erst zu finden *
Findet typischerweise die einfachste Struktur, die gerade noch
funktioniert (KISS-Prinzip)
 * Die Daten bleiben menschenlesbar.

Nachteile:
 * Typos und Anfängerfehler bedürfen einem stetigen Grundrauschen von
Korrekturen (und Leuten die das dann auch machen)
 * "leere Seite" - Phänomen, wenn Leute einfach garnicht wissen, was sie
eingeben sollten
 * Die Proxies müssen erstmal programmiert werden (Aufwand + Wartungsaufwand)



> if (k == "Postleitzahl") {
>   if (lat > 20) {
>     plz = v;
>   } else {
>     hausnummer = v;
>   }
> }

Das wäre zwar EINE Lösung einen Filter zu schreiben, aber mit Sicherheit
nicht die Beste.

Falls also jemand ein Tool schreibt, das gleichermaßen für typische
Infrastruktur in Suaheli und Deutschland gültig ist, dann sollte der
Filter, mit dem er die Daten beim Import entsprechend umwandelt schon ein
wenig komfortabler konfigurierbar sein ;-). Wie Ben schon meinte, gibt es
begründeten Zweifel, dass sich ein auch nur annähernd gemeinsamer Nenner
für alle Länder finden lässt.


>> Mal ernsthaft, jeder, der de.wikipedia.org eintippt, will so viel wie
möglich auf deutsch haben
>
> Dass soll ja auch jeder, der auf de.openstreetmap.org kommt, auch wenn
er schauen will, wo es in London Bäckereien gibt. :)

Will aber niemand.

Nein, was ich meine ist: Die Interessen bei ortsbezogenen Daten sind sehr
lokal ausgeprägt. Anfragen von Deutschen werden fast immer Daten
betreffen, die aus Deutschland kommen. Diese Eigenschaft kann man nun
entweder nutzen, ignorieren oder verteufeln.


> Die POIs sollten ja außerdem maschinenlesbar bleiben, damit der Nutzer
einfach nach der nächsten Tankstelle suchen kann, und nicht nach
amenity=fuel || ort=tankstelle || ...

Die ursprüngliche Idee der Tags war es, *menschen*lesbar zu sein.
Wiki-Titel oder flickr-Tags sind auch auf Menschenlesbarkeit optimiert. Es
gibt trotzdem einige Tools, die diese auswerten.


(Inwieweit Dienste wie Wikipedia oder flickr mit den Bedürfnissen von OSM
vergleichbar sind, ist noch herauszufinden.)



>> Und allen deutschen Nutzern will ich nicht zumuten, den Namen von allen
Sachen auf englisch zu wissen.
>
> Wenn die Nutzer schon so zahlreich sind, dass einige unter ihnen nicht
einmal unter http://wiki.openstreetmap.org/index.php/De:Map_Features
nach schauen können, wie den eine Tankstelle zu beschriften ist, wird
sowieso eine Eingabeschablone nötig werden.

Erstens ist Map-Features nur eine von vielen Möglichkeiten, Struktur in
die Tags zu bekommen und zweitens muss nicht jeder Nutzer alle relevanten
Tags für alle derzeit existierenden Tools eintragen wollen.


> Allein schon um die Tippfehler zu reduzieren.

Die typische Behandlung von Tippfehlern in frei editierbaren Systemen wie
dieses sind Gelegenheitskorrekteure, die bei Bedarf den Fehler "einfach
schnell" korrigieren. Bleibt abzuwarten, ob OSM für solche Leute
ansprechend ist (oder ob wir diese überhaupt benötigen. Systeme mit festen
Strukturen haben viel weniger Probleme mit Schusselfehlern).


> OpenGeoDB ist GFDL, OSM CC-BY-SA-2.0, die beiden Lizenzen vertragen sich
nicht.

Dies ist ein gutes Beispiel, warum Toolprogrammierer immer "Imports" von
Daten statt "direkten Zugriff nur auf das aktuelle Datenschema" anstreben
sollten.

Es wird immer andere Projekte geben, die interessante, aber für den
OSM-Server direkt unzugängliche Daten enthalten.

In einem System aus Filter-Proxies zwischen OSM-Server und Tool wäre es
leichter, OpenGeoDB als zusätzliche Importquelle einzubinden. ;-)

Ciao, Imi




Ciao, Imi





Mehr Informationen über die Mailingliste Talk-de