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
_______________________________________________
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de
