[Talk-de] Keine Vorwahlen?

[Frederik Ramm]

Hallo Frank,

> Sicherlich ist die Masse derjenigen, die das Datenmaterial zusammentragen,
> in erster Linie nur daran interessiert, ad-hoc ihre "eigenen" Karten rendern
> und frei verwenden zu können. 

Das stimmt;

[...]

> Wenn es also überhaupt gehen könnte, auch solche ehrgeizigen Ziele
> irgendwann einmal zu erreichen, dann meines Erachtens nur auf die Weise,
> dass man eben doch ein paar mehr verbindliche Standards (auch und gerade,
> was die Tag-Bezeichnungen betrifft) für die Datenauszeichnung festlegt - ich
> weiß, ich weiß, derzeit ebenfalls noch absolut nicht mehrheitsfähig ... 

Ulkigerweise wuerde der Grossteil der Leute da gar nicht aufschreien. 
Die Mapper waeren zu 99% gluecklich, wenn man ihnen einen Katalog 
vorsetzen wuerde und sagen wuerde: So wird gemappt. Die wollen gar nicht 
ihre eigenen Sachen erfinden und die Freiheit des Modells nutzen; deren 
Spass ist dann am groessten, wenn sie irgendwas korrekt mappen koennen 
und es fuer alles, was sie eingeben wollen, auch passende Tags gibt. 
Irgendwelche Vorschriften wuerden die gar nicht stoeren, die waeren 
meist sogar froh darueber.

> Und falls dies alles nichts nützt, weil zu viele Querdenker wie ich alles
> wieder ganz anders machen würden als ich: Was spräche denn gegen die
> Initiierung eines Unterprojektes, das sich zum Zwecke verbesserter
> Erfassungssoftware dieser Aufgabe der verbindlichen Standardisierung (und
> evtl. auch der schrittweisen sinnvollen Erweiterung des Datenmodells -
> natürlich unter Erhaltung der Abwärtskompatibilität) verschreibt?

Der Knackpunkt ist nicht ein gutes Ordnungssystem fuer Tags. (Ich 
glaube, da wird Andy Robinson auf der SOTM-Konferenz irgendwelche 
Vorschlaege machen, die da in Richtung einer besseren Standardisierung 
gehen.)

Der Knackpunkt ist (in meinen Augen) ein erweitertes Datenmodell, das im 
einfachsten Fall dem, was wir haben, generische Objekte und Relationen 
hinzufuegt (so dass man z.B. sagen kann: Es gibt ein Objekt 
"Autobahnkreuz Breitscheid" und die folgenden Strassenstuecke gehoeren 
da alle dazu). Im Bestfall wird das Datenmodell komplett umgestellt, 
z.B. auf etwas GDF-artiges (siehe unser Wiki). Eine 
Abwaertskompatibilitaet wird in beiden Faellen nicht existieren, 
allenfalls eine Konvertierbarkeit von Daten.


Wenn ich mehr Zeit haette, dann wuerde ich so ein neues Datenmodell 
einfach mal fertig entwickeln, einen Server dafuer aufsetzen, alle 
existierenden Daten einlesen und einen oder zwei der existierenden 
Renderer und Editoren darauf anpassen und dann sagen: Schaut her, so 
koennte man das machen, und seht, was ich alles gutes damit kann. (Man 
muss ja schon immer den praktischen Nutzen von den coolen Aenderungen 
demonstrieren, die man macht.) Selbst wenn die resultierende Software 
nicht sofort fuer OSM uebernommen wuerde, so koennte man sie durchaus 
als die bessere Alternative am "Markt" platzieren - es wird immer genug 
Leute geben, die die OSM-Daten importieren und irgendwas damit machen 
wollen, und wenn unsere Software besser mit OSM-Daten umgehen kann als 
OSM selbst...

Dass ich diese Zeit nicht habe (und auch nicht den Kampfgeist, der 
noetig waere, die Sache am Ende dann auch durchzudruecken), haelt mich 
derzeit davon ab, viel Gehirnschmalz zu investieren - weil ich weiss, 
dass es ohne eine Vorzeige-Implementation alles keinen Sinn hat.

Ich hatte mal angefangen, ein neues Datenmodell zu entwickeln (Paper 
dazu auf Englisch: 
http://www.remote.org/frederik/tmp/towards-a-new-data-model-for-osm.pdf).

Vielleicht kriegen wir ja mal ein Team zusammen, das sich die Aufgaben 
teilen kann, und gehen das gemeinsam an.

Aber wie gesagt, ein einheitliches System fuer Tags ist das kleinste 
Problem, glaube ich.

Bye
Frederik

-- 
Frederik Ramm  ##  eMail frederik at remote.org  ##  N49°00.09' E008°23.33'