[Talk-de] Mehr OpenStreetMap Softwareentwicklung und die Engineering WG

[Tim Teulings]

Hallo!

Als Autor von libosmscout antworte ich mal.

>> On Tue, 2011-10-11 at 10:27 +0200, Nils Faerber wrote:
>>> 1. Effiziente lokale Datenspeicherung und für eine effiziente und
>>> schnelle lokale Abfrage.
>> [...]

Ja.

>>> 2. Effizienter und "state-of-the-art" lokaler Map Renderer.
>> [...]

Bei einem Renderer, der eine Map in der Größenordnung <200ms liefert, 
ist die Qualität der Map immer ein Kompromiss. Zugegeben sind die 
Datenstrukturen und Datenqualität von OSM auch nicht immer hilfreich 
(aber das macht es ja nur aufregener ;-)). Mein Bestreben ist es eine 
gute Qualität abzuliefern bei sinnvoller Performance. Ggf. sind 
erweiterte Funktionalitäten, an/abschaltbar zu gestalten. Ich versuche 
auch eine hohe Flexibilität bzgl. der Optik der Map zu ermöglichen, aber 
Performance erzwingt hier eben bestimmte Kompromisse.

>>> Oh - sollte soetwas wider Erwarten doch bereits existieren, und ich habe
>>> mich danach schon wund gegoogled, nehme ich sachdienliche Hinweise sehr
>>> gerne entgegen!
>>> Aus lauter Verzweiflung habe ich mir jetzt schon ein Garmin Nüvi in der
>>> Bucht geschossen, damit ich wenigstens ansatzweise OSM Karten für
>>> Navigation verwenden kann, aber das kann ja echt nicht die Lösung sein...
>>
>> Hast du dir libosmscout [1] schon angesehen? Eingesetzt wird das z.B.
>> schon in MoNav [2], zusammen mit dem extrem schnellen MoNav routing
>> daemon.

Es hat zwar Überlegungen gegeben, libosmscout für das Map-Rendering in 
Monav zu integrieren, dies ist aber noch nicht geschehen. Der aktuell 
verwendete Renderer ist ein anderer. Von den Screenshots her ist meinem 
persönlichen Empfinden nach libosmscout "schicker", aber so etwas ist 
immer Geschmackssache.

> Recht sicher, aber mal sehen, was war das nochmal...
>
>> [1] https://wiki.openstreetmap.org/wiki/Libosmscout
>> [2] http://monav.openstreetmap.de/
>
> Ah, ja, richtig, hatte ich!
> Das ist in der Tat einer der vielversprechenderen Ansätze, gefiel mir
> ganz gut, war nur etwas frickelig ans Laufen zu bekommen (also außerhalb
> von Monav.

Sollte es Probleme geben, sollte man mich kontaktieren. Noch besser ist 
die Verwendung der entsprechenden Mailingliste.

> Teile davon könnte man sicherlich extrahieren und für den von mir
> skizzierten Zweck verwenden - oder vielleicht gleich das ganze OSMScout?
> Dann wäre es nur noch eine Frage, die Software zu verallgemeinern, damit
> sie breit eingesetzt werden kann. Also gute Trennung von Renderer,
> Kartendaten und Routing, damit ggf. auch mal eine der Komponenten gegen
> eine andere getauscht werden könnte.

libosmscout ist so modular designed (die Implementierung ist da 
sicherlich noch nicht perfekt), dass der Import, der Zugriff auf Daten 
sowie das Rendering auf gemeinsamen Datenstrukturen aufbauen. Es sollte 
aber möglich sein, einen Import zu schreiben, der z.B. nicht auf *.osm 
oder *.osm.pbf Dateien aufbaut, so lange die Daten den grundlegenden OSM 
Strukturen entsprechen. Ebenso sollte die Schnittstelle der Datenbank 
(Zugriff auf die beim Import generierten Dateien) auch durch eine andere 
Implementierung ersetzbar sein. Schließlich greift der Renderer nicht 
direkt auf die Datenbank zu, so dass prinzipiell auch Daten aus einem 
Online-Zugriff in den Renderer gesteckt werden können.
Integration von Routing ist aktuell eher provisorisch würde aber 
entsprechend implementiert.

> Das letzte mal als ich mir das angesehen hatte, war der Renderer noch
> stark eingeschränkt, d.h. es gab kein richtiges sinnvolles API, um von
> einer Applikation aus den Renderer als Widget einzubinden und zu
> beeinflussen (Center-Koordinate setzen, Rotation etc.).
> Alles machbar, keine Frage! Müßte man nur den libosmscout Author mal
> fragen und ggf. zusammenarbeiten.

Feedback/Anwender Herzlich willkommen :-)

Aktuell arbeitet der Renderer mit verschiedenen Backends (in 
verschiedenen Stadien). Das cairo Backend ist am fortgeschrittesten, 
gefolgt von einem libagg und Qt Backend. Es gibt auch Anfänge für ein 
SVG Backend. Neue Backends zu schreiben ist relativ unaufwändig.

Eine Abstraktion über das eigentlich "ich rendere in ein Canvas" in 
Richtung "Widget" ist aber sehr schwierig. Ein Gtk Widget (Gtk 2 oder 
Gtk 3?) und ein Qt Widget (oder doch besser zur Verwendung in QML und 
Co.?) unterscheiden sich schon sehr, unterschiedliche APIs für 
Multithreading aber auch unterschiedliche Anforderungen eines Clients 
(Monav hätte gerne Tiles, die Beispielprogramme rendern immer den 
sichtbaren Auschnitt) erzeugen beliebig viele Varianten von Widgets - 
die dann doch nicht passen. Die Personen, die libosmscout zum Laufen und 
integriert bekommen haben, hatten Aufwand in T Bereich Tage. Für 
jemanden, der Mal "eben schnell" ein vollständiges Programm im Kontext 
Routing,POI etc... schrieben will, ist dies der geringste Aufwand und 
meiner Meinung nach sollte das kein Hinderungsgrund sein. Tatsächlich 
habe ich bereits angeboten, entsprechende Widgets zu integrieren, dann 
aber als Library "on-Top" der bestehenden libraries.

Rotation ist in libosmcout aktuell die Aufgabe das Anwenders beim 
Ansteuern des Backends. Die meisten Backends (Cairo, Qt, libagg) bieten 
an, entsprechende Koordinatentransformation transparent durchzuführen. 
Eine entsprechende Tranformation in den Renderer selbst zu integrieren 
wäre aber auch kein Problem.

> Aber vielen Dank für den Tip da nochmal zu gucken!
> Die Screenshots von Monav sehen verflixt gut aus, ich bin begeistert! Da
> hat sich doch Einiges getan, seitdem ich das letzte mal geschaut hatte.
> Werde ich mir gleich auf einem N900 instalieren *freu* :)

Das ist (noch nicht?) libosmscout.

> Doch nach wie vor denke ich, daß die OSM Community auch Infrastruktur
> für Entwickler fördern sollte - also eben Bausteine fördern, die von
> Applikationsentwicklern einfach benutzt werden können, um interessante
> Applikationen zu (er-)schaffen. Libosmscout ist da schon sehr weit vorne!

Das höre ich gerne :-)

Entsprechende Gedanken waren der Hintergrund der Entwicklung. Mein 
persönliches Ziel war es nie, eine eigene Navigationssoftware zu 
schreiben sondern anderes dies zu ermöglichen. Auch mit mittlerweile 
günstigen Datenflatrates gibt es genug Situationen, wo Offline Rendering 
eine gute Alternative ist (Ausland, bei schlechter Abdeckung, im Fall 
von Katastrophen).

Wie auch mehrmals in der Vergangenheit hier noch mal der Aufruf: Wer 
Interesse hat, sollte Kontakt aufnehmen es gibt für verschiedenste 
Bereich Möglichkeiten der Mithilfe. Selbst reines (negatives) Feedback 
ist hilfreich.

-- 
Gruß...
    Tim