[Talk-de] Entwicklung eines Navi für OSM Daten

[Nils Faerber]

Am 19.10.2011 19:51, schrieb hannes:
> Aus dem Thema:
> Re: [Talk-de] Mehr OpenStreetMap Softwareentwicklung und   
> die?Engineering WG
> 
> Am 17.10.2011 16:26, schrieb Sven Geggus:
>> Nils Faerber<nils.faerber at kernelconcepts.de>  wrote:
>>
>>> Habe nochmal etwas weiter geguckt - leider ist es nach dem Release 0.3
>>> von Monav reichlich still geworden. Seit April 2011 keine Updates mehr
>>> im Code - schade eigentlich, die Routing-Funktion war schon brachial
>>> schnell.
>> Die Routingfunktion ist in einem separaten daemon implementiert, der z.B.
>> auch von Marble verwendet wird.
>>
>> Prinzipiell sollte es daher möglich sein für Android und Konsorten native
>> frontends zu schreiben.
>>
>> Gruss
>>
>> Sven
>>
> Ich hab mal ein neues Thema angefangen weil im alten Thema über
> verschiedene Dinge diskutiert wurde und wir Kai sein Thema geklaut
> haben. Tschuldigung Kai!

:)

> Weiter oben im alten Thema wurde das Problem mit den hohen
> Einstiegshürden aufgezeigt, das sehe ich genau so. Die Einarbeitungszeit
> um sich in die Gedanken eines anderen einzuarbeiten ist einfach zu lang.
> Es ist doch schade, da macht sich jemand an die Arbeit und schreibt 
> z.B. ein Navi, da geht dann mehr Zeit rein als gedacht und die Arbeit
> wird eingestellt. Die bis dahin geleisteten Mühen sind verloren, weil es
> zu aufwändig für andere ist sich einzuarbeiten.
> Ich kann mir vorstellen das es etliche Leute wie mich gibt, die gern an
> einem Programm mitarbeiten würden aber unter zeitlicher Begrenzung. Ich
> denke an langfristig 5 Std. pro Woche, in der Anfangsphase sicher etwas
> mehr. Damit so jemand nützlich sein kann müsste ein Projekt
> 
> *** in möglichst viele abgeschlossene Module aufgetrennt sein, mit
> dokumentierter Schnittstelle. Geht das überhaupt? Na, wenn nicht, das
> Umdokumentieren nicht vergessen.

Die Modularisierung an sich ist schon ein großer Schritt vorwärts und
IMHO fast wichtiger als Doku dazu. Wenn die Module klar abstrahiert sind
und gute APIs haben, dann sollte automatisch erzeugte API Doku jedem
Neuling schnell einen guten Einstieg ermöglichen.

> *** für Neulinge dokumentiert sein. Ich meine grundsätzliche Dinge
> sollten erklärt werden.
> Beispiel:
> Ich habe mich mal mit einem Router auf OSM-Daten beschäftigt:
> 
> typedef struct _Cross {
>     struct _Way *a[MAXWAYPERCROSS];
>     gfloat lon,lat;
>     gint64 id;
>     guchar flag;
> } CrossT;
> 
> typedef struct _Way  {
>     guchar flag;
>     gchar type;
>     GList *glp;  //g list pointer
>     gint anznd;
>     guint64 id;
>     //gfloat length;
>     CrossT *from, *to;
> //    gchar name[100];
> //    gchar ref[100];
>     gchar *name;
> //    gchar *ref;
> //    struct _koords {gint64 nd; gfloat lon, lat;} k [MAXND];
>     gint64 nd[MAXND];
> } WayT;
> 
> Alles klar? Wohl kaum. Dabei sind das die wichtigsten Strukturen.
> /*
> Der Router arbeitet auf einer Karte die aus Wegen besteht, diese haben
> eine Länge, einen Namen, eine Geschwindigkeitsbegrenzung etc. Die Wege
> sind am Anfang und am Ende an Kreuzungen angeschlossen. Die Kreuzungen
> enthalten Zeiger auf die angeschlossenen Straßen/Straßensegmente(Way).
> */
> Jetzt ist es klarer - vermute ich. Wenn man dann noch den
> Standartalgorithmus zum routen kennt ist es fast klar wie das Programm
> aussieht.

Entweder so, was aber meist etwas mehr Arbeit ist, oder eben API Doku
mit einem Doku Tool wie Doxygen oder GtkDoc erzeugen. Das ist dann recht
einfach und das macht auch der Entwickler des APIs sicherlich gerne mit.

> *** die alten Mitarbeiter im Projekt sollten für Neulinge Arbeiten
> definieren, beschreiben und die Einstiegspunkte aufzeigen.
> Das dient alles dazu einem Interessierten den Einstieg zu erleichtern
> und zu motivieren dabei zu bleiben.

Wenn es möglich ist, auf jeden Fall, ja!

> Kann das funktionieren? Keine Ahnung! Aber ich würde es so versuchen.
> 
> Wie ist es, wollen wir versuchen ein Navi herzustellen? Hat jemand Lust
> mitzumachen?

Ja!
Zeit ist begrenzt, aber ich kann von mir aus garantieren, daß ich das
sehr nahe verfolgen werde. Ob und wieviel Code ich dazu beitragen
könnte, kann ich so kaum abschätzen.

> Wie wollen wir starten? Fangen wir von vorne an und arbeiten Teile von
> monav oder gosmore ein oder bauen wir auf monav auf oder...

Keines der Dinger ist IMHO modular genug.
Wir sollten uns zuerst darauf konzentrien, Module zu beschaffen, zu
"borgen" oder die Entwickler der anderen Lösungen zu übrzeugen,
interessante Teile in einer Modulform zur Verfügung zu stellen.

Die wichtigsten Module/Teile haben wir ja schon hinreichend diskutiert:

1. Datenhaltung - also die Kartendaten möglichst effizient speichern und
darauf zugreifen

2. Map Rendering - aber so, daß es möglichst GUI Toolkit frei ist. Cairo
ist da vielleicht ein guter Ansatz, da man einen Cairo Canvas in fast
alle Toolkits irgendwie einbinden kann und die Renderingqualität einfach
gut ist.

3. Routing - muß auf den Kartendaten arbeiten und eine Schnittstelle zum
Map Rendering bieten, dazu noch die üblichen Funktionen für
Fahranweisungen etc. Letzteres sollte nur eine definierte Ausgabe
liefern, die dann eine Applikation verarbeiten kann, wie sie es für
richtig hält - TTS, Grafik etc.

4. Referenz Applikation - die dann die Komponenten aus 1-3 in einer
Applikation vereint und an Dinge wie ein GPS anbindet.


OSMScout bringt da schon eine Menge für 1. + 2. mit. Tim bräuchte nur,
wenn ich das richtig verstanden habe, noch etwas Unterstützung, um den
Map Renderer etwas leichter integrierbar in Toolkits zu machen - ich
würde mir da als alter GTK+ Hacker ein GTK+ Map Widget wünschen, ein Qt
Hacker könnte ein Qt Widget daraus machen etc.

Eine Navi Applikation stelle ich mir dann letztlich recht simpel vor.
Darstellung des Kartenwidgets, anbinden des GPS an das Kartenwidget,
damit die Karte dem GPS folgt und Anbindung des GPS an die Routing
Engine, das ganze GUI Zeug zur Eingabe von Ziel-Adressen oder Ziel-Punkt
auf Karte wählen, Verknüpfung von Routing Engine mit dem Kartenwidget
(Darstellung der Route) und ggf. weitere Darstellung der Fahranweisungen
(Pfeile, Entfernungen, TTS). Wenn es so modular ist, dann werden wir
IMHO schnell ein knappes Dutzend Navi Apps darauf aufsetzend sehen.

Die ganze Infrastruktur kann dann auch sicherlich in noch andere
Applikationen als in Navis enden - Geocaching, mobile OSM "Editor" oder
Mapping Helfer etc.


It is about time - let's do it!

Wie doof ist das denn, daß wir da tolles Kartenmaterial haben, aber die
Brot-und-Butter Applikation "Navi" nicht auf offene Füße stellen können?
Die Krücke via mkgmap und Garmin Navi kann doch echt nicht Sinn der
Sache sein... ohweh, ich sehe dann schon die Fragen nach der OSM-Navi
Applikation auf Navi Geräten aufkommen - und dann dürfen wir noch Linux
Ports auf Navi Hardware anfangen ;)

> Gruß
> Hannes
Viele Grüße
  nils

-- 
kernel concepts GbR        Tel: +49-271-771091-12
Sieghuetter Hauptweg 48
D-57072 Siegen             Mob: +49-176-21024535
http://www.kernelconcepts.de