Hallo, > Das kann man doch ueberhaupt nicht vergleichen. OSM ist ein > "Crowdsourcing"-Projekt. Da kommt es nicht auf einzelne Entwickler an, > sondern auf die Masse von Mitmachern, von denen jeder nur ein kleines > bisschen zum Erfolg beitraegt. So wie eben die Wikipedia auch; da gibt > es zwar einen harten Kern von Aktiven, aber ohne die Massen von > Leuten, die da mitmachen, koennten die nichts erreichen.
Wenn schon der Vergleich mit KDE hinken soll, hinkt der Vergleich mit Wikipedia noch viel mehr. Wikipedia ist eine Ansammlung von Texten und Bildern, die schwach miteinander verknüpft sind. Eine Straßenkarte ist ein straffes mathematisch abgesichertes Gebilde. Kommt eben drauf an, was man will. Ein GIS, das die Daten nur schwach verknüpft kann man so aufziehen, aber solange eine digitale Karte eine ziemlich zentrale Rolle hat, gibts sehr strenge Regeln. Der kürzeste Weg von X nach Y ist eine exakte Lösung einer exakten Problemstellung und wenn OSM was anderes ausgibt, arbeiet OSM fehlerhaft. > Wenn die Daten erstmal da sind, dann kommen die Anwendungsprogram- > mierer ganz von allein. Nö, das sollte Hand in Hand gehen. > Erst ein schoenes Korsett aufbauen und das > dann von willigen Arbeitsbienen nach Vorschrift befuellen lassen, das > geht halt (hier) nicht. Warum diese Panik vor einem angeblichen Korsett um das es hier gar nicht geht? Es geht nach wie vor darum, das Erarbeitete zu dokumentieren und zu schützen und nicht darum ein Korsett in den leeren Raum zu stellen. > Die Programmierer, die wir brauchen, tun sich > nicht durch perfekte Algorithmen und coole Optimierungen hervor, > sondern dadurch, dass sie mit "Crowdsourcing" angemessen umgehen > koennen. Hier sind keine Elfenbeinturmbastler gefragt, die nur mit > idealen Bedingungen und punktfoermigen Massen rechnen koennen. Siehe oben: es gibt falsch und richtig. Wenn mich das Navi auffordert, gegen die Fahrtrichtung in die Einbahnstraße abzubiegen, hat das Navi (im KFZ-Modus) einen Fehler gemacht, da gibts nichts dran zu deuteln. Egal, ob Crowdsourcingprogger oder Elfenbeinspezialist - diese Randbedingung steht. Erwarte ich deshalb, dass alle OSM-Daten von Anfang an perfekt sind und tolles Routing ermöglichen? Natürlich nicht. Aber was ich schon gerne sehen würde, ist ein Weg dorthin und genau der fehlt mir. Derzeit wird alles immer noch chaotischer und undurchsichtiger und alles was in Richtung Qualitätssicherung und Anwender-API geht, wird abgewürgt. > Wer > fuer OSM gute Software machen will, der muss mit unvollstaendigen, > falschen, "schmutzigen", unvorhergesehen strukturierten Daten umgehen > koennen. Das ist eine ganz andere Welt als bei der kommerziellen > Konkurrenz, wo von oben festgelegt wird, wie's gemacht wird, und dann > faehrt der Video-Van los... Und genau das ist eine unmögliche Forderung. Da kannst du genauso von den Leuten erwarten, dass sie C-Programme schreiben, die mit einem Pointer, der irgendwo hinzeigt, bitte etwas sinnvolles machen sollen. Ein falscher Wert, der einen falschen Graphen erzeugt, erzeugt ein falsches Ergebnis - so einfach ist das. Und die Attributsebene? Ich kann schon ein Programm schreiben das 100erte von ähnlichen Beschreibungen eines Werts filtert und irgendwie interpretiert. Dann habe ich aber mit viel Aufwand etwas erreicht, das immer noch viel ungenauer ist als ein popliger Zahlenwert, der mit einer genauen Definition verbunden ist. Damit soll man Anwendungsentwickler anlocken? > Schau Dir doch mal das MediaWiki an und was das (software-design- > maessig) fuer ein Haufen Schrott ist. Hat die Wikipedia aber bis jetzt > nicht zu Fall gebracht. > Davon, jetzt erstmal auf die Bremse zu treten und sich vernuenftige > Software zu ueberlegen, halte ich wenig. Bis wir uns auf vernuenftige > Software geeinigt haben, ist das Projekt tot ;-) Wer will denn auf die Bremse treten, davon war nie die Rede. Man sollte sich nur vielleicht überlegen ob es Beschleunigung um jeden Preis sein muss. Derzeit ist dieser Preis, dass die vorhandene Datenbasis verunstaltet wird. Da das Projekt mich als Elfenbeinturmentwickler nach deiner Aussage nicht brauchen kann, mach ich inzwischen mit den nativen AND-Daten weiter und hab mir einen schnellen Einlesefilter dafür geschrieben. Deren Shapeformat ist wirklich alles andere als schön, hat aber einen Vorteil - es ist sauber dokumentiert und kann alles, was man fürs Routing braucht. Ich mag lieber coole schnelle Algorithmen machen, statt ein 'wie taggen wir denn heute'- Schätzeisen. In diesem Sinne - Danke ans OSM-Projekt für die AND-Daten und als Tagger stehe ich weiterhin zur Verfügung. Grüsse Hubert -- Psssst! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger _______________________________________________ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de