Von NAVIT träumen...

Hallo Leute,

da ich mich seid einigen Wochen nun beim NAVIT Projekt rumtreibe, wollte ich euch mal um ein paar Anregungen bitten.
Ich möchte mit Nutzern sog. “User stories” erstellen, in denen man die Vision eines funktionierenden Ablaufs eines Navis detailliert festhält. Also auf welchem Gerät läuft es, wie ist das persönliche Szenario (z.B. Autofahrt zur Tante, man kennt sich insb. im Zielgebiet nicht aus, …). Das ist quasi auch so eine Art freies Gedankenspiel, was aber die derzeitigen Probleme/Beschränkungen von NAVIT unberücksichtigt lässt. Mit Hilfe solcher Berichte soll man insb. Gemeinsamkeiten berücksichtigen können, was dann später eventuell in eine neugestaltete Architektur von NAVIT einfließen kann. Ich habe mal einfach sowas angefangen, mit dem Szenario “Installation”
http://wiki.openstreetmap.org/wiki/User:!i!/NAVITng/User_story_install
Und hier war jemand schon aktiv mit einem recht komplexen Szenario (deshalb auch Usecase)
http://wiki.navit-project.org/index.php/User:Xenos1984/Navit_use_case

Ihr könntet in dieser Form auch von Situationen berichten, wo gerade NAVIT kläglich versagt hat, oder über Aspekte, die euch bei kommerziellen Navis sehr gut gefallen haben und ihr euch wünscht.
Wie bei OSMBugs solltet ihr aber daran denken, dass ihr die wesentlichen Hintergründe auch erläutert, da der Leser diese ja nicht kennt und quasi “keine Orientierung” hat, was euch nun gefällt und was nicht. Dabei darf das ganze aber auch nicht ausarten, sonst mag das leider keiner mehr lesen…
Persönliche Hinweise und Erläuterungen würde ich deswegen in eine seperaten Block am Ende auslagern.

Es soll dabei nicht darum gehen, was bei NAVIT alles gerade nicht klappt (dafür gibt es ja den BugTracker) und auch nicht primär darum, was bei der Entwicklung gerade schief läuft (es weiß dort jeder, dass z.B. Usability gerade nicht so toll ist). Vielleicht auch gar nicht, wie ein Problem mit einer konkreten Implementierung gelöst werden könnte (z.B. der Kompass soll so und so aussehen), sondern eher die Entwickler die Hintergründe und das Warum verstehen lassen (z.B. der Kompass sollte irgendwie verständlicher werden, um bei der Autofahrt schnell gedeutet zu werden).
Würde mich sehr freuen, wenn wir den Entwicklern zeigen könnten, dass durchaus Interesse an ihrer Anwendung besteht und das es nicht darum geht, jemanden (mal wieder) vorzuwerfen was alles nicht geht, sondern gemeinsam das zu finden, was sich Leute wünschen und vielleicht machbar ist. Daraus kann man dann konkrete Verbesserungen ableiten, diese nach Aufwand/Interesse/… gewichten und auf eine Roadmap einordnen.

Das Ganze bitter aber erst einmal nicht an die große Glocke hängen. Bis jetzt haben sich da kaum Leute aus dem NAVIT Core-Entwicklerteam geäußert und solche Vorschläge zu gravierenden Veränderungen von Außenstehenden brauchen natürlich Zeit. Da wäre es kontraproduktiv, wenn 500 Mapper Wunschlisten an den Weihnachtsmann schreiben, oder den Entwicklern probieren zu erklären wie man alles “ganz einfach” lösem kann
Es wäre aber schön, wenn vielleicht 5…10 Leute im Wiki mal während der Feiertage sowas verfassen könnten, gerne könnt ihr euch dabei an den bisherigen Vorlagen orientieren.

Hintergrund:
Vielleicht wisst ihr ja, dass ich mich insbesondere auch damit beschäftige, OSM zu promoten und Community Aspekte zu managen. Nach vielen Gesprächen in den letzten Monaten, bin ich aber zur Ansicht gelangt, dass uns mittlerweile insbesondere nur noch eine gut funktionierende offline Navigations-Anwendung helfen wird, neue Leute für OSM zu begeistern (in GIS, IT und Science kennt man uns einfach mittlerweile).
Naja da ich ja damals mit geholfen habe die Software zu katalogisieren, habe ich mir mal überlegt, der NAVIT Community etwas zu helfen. Damit meine ich nicht, deren Code zu entführen und etwas neues zu starten, sondern den Entwicklern die Situation bewußt zu machen und gemeinsam nach Maßnahmen zu suchen, wie man die Probleme angehen könnte. Ein bisschen Brainstorming habe ich hier schon gemacht:
http://wiki.openstreetmap.org/wiki/User:!i!/NAVITng

Wohl wahr … deine (eigentlich) Intension bleibt mir aber trotz langem Text unklar.
Willst du bei NAVIT den “Restart-Knopf” drücken ?

Gruß Klaus

Ein Webforum wie dieses hier ist genau der richtige Ort, um etwas nicht an die große Glocke zu hängen.

Ich kann nur hoffen, dass du deine Ansicht noch einmal überprüfst und diesen, mit respektvollem Verlaub, Unsinn nicht auch noch promotest.
Aber wenn es tatsächlich so ist, dass nur noch eine Navigationsanwendung für neue User sorgen kann, ist es um OSM schlimm bestellt.
Glaube ich aber nicht, weil ich in den letzten Monaten z.B. zwei Leute zum Mitmachen bewegen konnte, denen es egal war, ob sie mit OSM navigieren können. Die haben ganz andere Interessen. Soll ja auch vorkommen.

Natürlich ist es sinnvoll, OSM auch auf dem Gebiet des Offline-Routings voranzutreiben - etwas gegenteiliges zu behaupten wäre Blödsinn. Deshalb kann ich !i! in diesem Punkt nur zustimmen, dass man gerade solche Projekte wie Navit unterstützen sollte, insbesondere was die Einbindung von OSM und die Nutzung von OSM-spezifischen Features angeht. Gerade weil wir so viele Features erfassen wie maxspeed, maxheight, width, surface etc., die man auch fürs Routing auswerten kann, sollte es möglich sein, mit OSM-Daten ein Routing hinzubekommen, das mit weniger genauen Daten gar nicht denkbar wäre. Und wenn man OSM auf diesem Gebiet promoten kann und damit mehr Interessenten für das Routing mit OSM gewinnen kann, bin ich zu 100% dafür.

Navit hat sich schon zu einem recht komplexen Programm entwickelt und hat einen ziemlich umfangreichen Quellcode. Wenn man da noch einmal komplett von vorne anfangen wollte, wäre das ein ziemlicher Aufwand. Zugegeben, es ist auch recht viel Aufwand, durch diesen Code durchzusteigen, geschweige denn ihn zu “entrümpeln”, zu verbessern und zu ergänzen. Aber auf diese Weise kann man sicher einiges erreichen, neue Features und insbesondere die Benutzerfreundlichkeit und Bedienbarkeit verbessern.

Um das Programm zu verbessern, muss man sich natürlich fragen, in welche Richtung die Entwicklung gehen soll. Und da kommt die Community ins Spiel: Welche Features sind gewünscht? Wie könnte man Navit komfortabler nutzen? Worüber ärgern sich die derzeitigen Nutzer? Wer möchte Navit wofür nutzen, und was steht ihm dabei im Weg? Genau solche Ideen und Anregungen sind gefragt.

Meinen Usecase hat !i! ja oben schon gepostet. Im Laufe der Zeit sind mir noch einige weitere Ideen in den Sinn gekommen, wie die folgende: In Programmen wie Marble oder QLandkarte kann ich z.B. GPX-Dateien laden und auf der Karte darstellen. Das würde ich mir auch für Navit wünschen - zusammen mit der Möglichkeit, diese auch gleich auszuwerten und z.B. Wegpunkte als Routingziele anbieten (Finde → Wegpunkt in der Nähe) oder Distanz und Kurs zu einem Wegpunkt anzeigen.

Wenn noch jemand solche Anregungen hat, immer her damit.

@!i!.. sorry, dass ich noch nicht auf deine PN geantwortet hatte. Bin noch nicht dazu gekommen. Werde mich aber hier auch reinbringen, da ich ja Navit auch intensiv nutze und noch weiter voranbringen will.
Jedenfalls, schon mal vorab etwas, das man bei Navit vorantreiben sollte: Adress- / Strassen-Suche innerhalb eines Gemeinde- bzw. PLZ-Multipolygons (dort, wo diese vorhanden sind) und zudem sollten noch die addr:= an den Gebäuden/Nodes berücksichtigt werden. Bis jetzt findet man ja nur Strassen, die in einem gewissen Umkreis um einem Place-Node sind und die Grenz-Multipolygone und addr:*-Tags werden nicht beachtet.

Vielleicht habe ich mich aufgrund des langen Textes auch einfach verklausuliert

Was ICH selbst machen möchte, ist NAVIT zu helfen eine Roadmap mit Fehlerbeseitigung/Umbau/neuen Features zu entwickeln und (sofern es mir möglich ist), an dieser mitzuarbeiten.
Dafür brauche ich/wir aber EUCH, denn nur weil ich eine Vorstellung davon habe, was NAVIT mal können sollte, muss das ja nicht repräsentativ sein. Ich bin ja nur ein Radfahrer und habe nicht mal ein Smartphone und bin dazu noch relativ IT-affin. Andere Nutzer, wie 50jährige PKW Fahrer oder Touristen, wünschen sich ja vielleicht sehnlich ganz andere Dinge?

Es geht mir ausdrücklich nicht darum, ein neues “besseres” NAVIT zu starten (weder könnte ich das, noch halte ich das für sinnvoll), oder zu forken (was ZAnavi tat). Wer sich mal all die Plattformen anschaut, auf denen navit bereits läuft und wie viel überall justierbar ist, merkt warhscheinlich schnell, dass das Problem gar nicht unbedingt technischer Natur ist. Gefühlt ist es eher, dass die zentrale Idee abhanden gekommen ist, was das Tool eigentlich leisten soll und es deshalb sehr schwer ist, einen guten Plan zur weiteren Entwicklung aufzustellen. Das ist noch nicht mal unbedingt die Schuld der Entwickler, denn im Jahr 2005 (als das Programm startete) sah die Welt noch ganz anders aus. Smartphones/Tablets gab es nicht und auch OSM war noch weit von dem entfernt, was es heute ist und kann

Ich habe vorher schon einige Leute “im Stillen” kontaktiert. Da aber einige Leute auch sehr allergisch reagieren, wenn sie nachhinein vor vollendete Tatsachen gestellt werden, habe ich das bereits jetzt auf eine etwas öffentlichere Stufe gehoben. Ich selbst habe mit diesem Vorgehen kein Problem, wollte damit nur klar machen, dass daran keine zu hohen Erwartungen geknüpft werden und nun nicht jeder twittert “NAVIT2ng deluxe gestartet !!!”

Wenn du das als “Unsinn” abtuest ist es ja ok und ich verschwende nur meine Zeit Klar, auch mir gelingt es den ein oder anderen für OSM zu begeistern und verfolge ja auch, welche neuen Mapper es in meinem Umfeld gibt.
Allerdings haben wir bisher “die Endnutzer” meiner Meinung nach (die ich wie gesagt auch gegen andere geprüft habe) zu wenig auf dem Schirm und aus meiner Erfahrung der Öffentlichkeitsarbeit meine ich zu sehen, dass aber alle aus dem “professionellen” Bereich wie GIS und IT uns kennen. Da wir spontan nicht dieselbe performante Online-Lösung wie Google Maps hinstellen können, erschien mir selbst die Bereitstellung einer guten offline Lösung (die ja rechtlich fast nur OSM bieten kann) als sinnvolles nächstes Ziel. Das muss natürlich nicht von jedem so gesehen werden, ich wollte nur erklären, warum ICH mich gerade JETZT dafür einsetze

@MHohmann Danke

@efred Null problemo, wollte dich damit nicht anspornen. Wie gesagt, wenn jemand sich über Weihnachten Lust hat sich ranzustzen wäre das schön. Es eilt ja nicht und bei NAVIT gibt es auch so ja genug zu tun

Ich denke das OSM bei der Offline-Navigation schon recht gut vertreten ist. Allerdings wohl primär auf eigenständigen Geräten. Das liegt aber auch daran, dass diese Geräte einige Vorteile gegenüber Smartphones&Co haben.

Manchmal hat sich ein Programm solange weiter entwickelt, bis es schwer wird a) Fehler zu beheben und b) Erweiterungen einzubinden.

Das ist dann der Zeitpunkt, wo man sich fragen muss, ob die vorhandene Programm- und Daten-Struktur für weitere Entwicklungen noch geeignet ist. Die Grundlagen sowohl der Daten- als auch der Programm-Struktur sind ja zu einer Zeit entstanden, als der heutige Funktionsumfang noch nicht abzusehen war. Daher sind sie heute für die Weiterentwicklung vielleicht eher hinderlich. Denke einfach mal an die Stichworte Spagetti-Code und Daten-Rucksack.

Heute weiß man, wie die Sache im Prinzip (und in vielen Details) funktioniert und kann daher besser geeignete, leichter erweiterbare Daten- und Programm-Strukturen als Basis für einen ReWrite nutzen.

Das Problem haben schon viele (OpenSource) Programme durchmachen müssen. Schau einfach mal in die Versionsgeschichte einiger Programme auf Wikipedia.

Edbert (EvanE)

Das stimmt schon Edbert, aber ich denke dazu muss man erst mal wissen, wohin man will. Dann kann man daraus Wünsche zur Weiterentwicklung herausnehmen und schauen, ob die vielleicht an die Grenzen der Architektur passen.

Verschiedene NAVIT Entwickler sind bis jetzt jedenfalls sehr optimistisch, dass das derzeitige Gerüst auch neuere Anforderungen abkann. Ich selbst bin noch nicht groß durch den Code gestiegen, weshalb ich dazu nichts sagen kann.
Strukturierte Programmierung ist leider bei leistungsschwachen eingebetteten Systemen nötig, auch um eine maximale Portabilität zu gewährleisten. Bei OOP gäbe es natürlich ein paar schönere Tools (UML, Refactoring, …) aber, die Leute haben ja nun schon ein paar Jährchen Erfahrung, insofern kann man da sicherlich auf Kompetenz zurückgreifen.

Bei der Navigation speziell jenseits des KFZ wären recht viele Profile nützlich, die für den Nutzer verständlich sind.

Mal ein paar Beispiele für Radfahrergruppen:
MTB-Anfänger, MTB-Fortgeschritten, City-Flitzer, Rennradler, Tourenbiker, Radwegradler ,… man findet sicherlich noch mehr.

und für Fußgänger:
Spaziergänger, Bin in Eile, Wanderer, Alpinist, … man findet sicherlich noch mehr.

Über die Profile wird dann gesteuert, wie gewisse Wege fürs Routing gewichtet werden.

Eine andere Baustelle ist die Inbetriebnahmen. App installieren, Kartendaten separat Laden und in ein Verzeichnis kopieren ist vielen Nutzern schon fast zu viel.

Nanu, ist da etwas an mir vorbeigegangen? Gibt es spezielle Geräte für die Navigation mit OSM-Daten? Oder wird OSM in größerem Stil dafür genutzt? Oder meinst du damit z.B. Dinge wie Garmin-Karten aus OSM-Daten, die dann auf Garmin-Geräten genutzt werden (wobei aber die Hardware und auch die Software darauf) unabhängig von OSM entwickelt wurden?

Als Vorteil von Navit (oder vergleichbarer Software) sehe ich, dass man es speziell auf OSM zuschneiden kann und damit auch OSM-spezifische Features nutzen kann, die man normalerweise nicht auf dem Plan hat, wenn man eine Navi-Software (oder -Hardware) entwickelt.

Mein Lieblingsbeispiel für Navi-Hardware in diesem Zusammenhang sind die TomTom-Navis. Die benutzen zwar von Haus aus ein geschlossenes Format und auch eine geschlossene Navi-Software, basieren aber auf Linux. Dadurch kann man relativ einfach eigene Programme darauf zum Laufen bringen. Insbesondere klappt das eben auch mit Navit und man kann OSM-Daten nutzen. Und schon hat man eine zur Navigation konstruierte Hardware mit Open Source Software und OSM-Daten.

Ja, da hast du allerdings Recht - dieses Problem kenne ich selbst auch. Auch von daher halte ich so ein Brainstorming wie dieses hier sinnvoll, um zu sehen, wie groß die Übereinstimmung zwischen dem derzeitigen Funktionsumfang von Navit mit den Wünschen der User ist. Wenn es nur Kleinigkeiten zu verbessern gibt, kann man die sicher im derzeitigen Navit-Code unterbringen. Aber wenn man wirklich von Grund auf etwas ändern möchte und dafür z.B. das interne Datenformat komplett umbauen muss, macht ein strukturierter Rewrite vermutlich mehr Sinn. Natürlich kann man auch in den einiges an Code einfließen lassen, der bereits besteht, wie z.B. Routingalgorithmen (sofern man an diesen nicht auch einiges umbauen möchte).

Da würde ich deine Liste mal um den Rollstuhlfahrer ergänzen Ein ideales Rollstuhlrouting mit Bordsteinhöhen etc. wird man zwar nicht so ohne weiteres hinbekommen, aber mir würde z.B. schon ein Profil reichen, das nicht über Treppen routet, sich sonst aber ähnlich zum Fußgänger verhält. Wenn man dann noch bestimmte surface=* ausschließen könnte, wäre ich mehr als zufrieden.

Ich weiß gar nicht, ob Navit (zumindest auf manchen Plattformen) schon ein automatisches Laden von Kartendaten unterstützt… ZANavi tut das (und das ist ja ein Navit-Derivat) - wobei ich dort allerdings von der geschlossenen Kartenstrategie nicht gerade begeistert bin und deshalb doch lieber Navit nutze, auch wenn es etwas mehr Handarbeit ist.

Mit eigenständigen Geräten meinte ich allgemein alle Geräte, die nur für die Navigation gedacht sind. Recht prominent sind da natürlich die Garmin-Karten, die allerdings die Software von Garmin nutzen. Aber OSM stellt ja nur die Daten zur Verfügung und keine Software. Von daher spielt es ja für die Verbreitung von OSM keine Rolle, ob die Routingsoftware nun von Garmin, Magellan oder sonstwem stammt.

Es gibt auch einige Geräte, die speziell mit OSM-Karten ausgestattet sind. Ich glaub von Medion. Wurden auch mal im blog.openstreetmap.de getestet.

Das mit den differenzierten Profilen hatte ich teilweise schon im Hinterkopf, nur nicht so feingliederig. Das ist ein guter Punkt!

Jups, auch die einfachere Installation muss angegangen werden und erscheint mir nach langem Studium der Dokumentation aufgrund der Modularität auch ganz gut machbar. So ein Downloadmanager wie im Android-Port wäre schon was, das könnte aber vlt. 2. Schritt in diese Richtung sein.

Es ist schon richtig, dass ein Neustart bedingt, dass man eine Zielvorstellung hat. Dafür ist deine Umfrage (bei den Endusern) sicherlich wichtig, um die Relevanz einzelner Ziele einschätzen zu können.

Ich denke mal, die Umsetzung von Adressen könnte so ein (Knack-)Punkt sein, bei dem sich die Frage stellt:
Vieles ändern/anpassen/erweitern oder
ReWrite und eine neue Basis für die Zukunft legen.

Wie gesagt haben viele Projekte den Punkt erreicht, wo die Zukunft eine neue Basis erforderte. Das geschah oft in der Form, dass Version 3.x zu Version 4(.y) weiterentwickelt wurde und parallel dazu eine Version 5 mit neuer Basis. So wird die Kontinuität gesichert und gleichzeitig Zeit für die Entwicklung einer neuen Basis geschaffen.

Strukturierte Programmierung (z.B. in C) muss nicht schlecht sein. Man kann viele Punkte der Objekt-orientierten Programmierung wie Datenkaspelung, Module für Funktionsgruppen, Datenzugriff zwischen Modulen nur über Funktionsaufrufe usw. auch in strukturierter Programmierung realisieren. Man muss es halt bewusst und von Hand machen.

Edbert (EvanE)

Siehe auch diese Wikiseite.

Also die Entscheidung, inwiefern dort mit Refactoring gearbeitet werden kann, oder ob man da sauber noch mal von vorne beginnen sollte, finde ich sollten nicht wir von außen treffen, sondern die Entwickler selbst. Diese müssen später ja auch mit diesen Lasten leben und haben eben auch die Erfahrungen, wo Sollbruchstellen sind.
Wie oben geschrieben, an der Stelle bitte erst mal die Diskussion auf Wünsche beschränken und Details/Hinweise zur Implementierung bitte noch etwas zurückstellen

Es ist sicher richtig, dass dies eine Entscheidung der Navit-Entwickler sein muss.
Betrachte es als Anregung insbesondere im Hinblick auf eine zukünftige Adresssuche.

Edbert (EvanE)