Hallo Nils.

Ich glaube nicht, dass eine solche API sinnvoll machbar ist.
Im Gegenteil würde eine solche API die Problematik des Preprocessings erneut verstecken. Eine Routing-Anwendung braucht ein anderes Datenformat als ein Renderer und wieder was anderes als eine lokale Restaurantsuche. Sinnvollerweise wird die Restaurantsuche außerdem nur ein kleines Subset der Datenbank überhaupt haben wollen, andere Anwendungen brauchen andere Teilmengen.

Der Zugriff ist komplett unterschiedlich: Suche ich in erster Linie nach Namen (Lokalsuche), nach Topologie (Router) oder nach geografischer Position ohne Berücksichtigung der Topologie?

Die Inhalte sind komplett unterschiedlich: Nur OSM-Editoren werden die komplette Datenbank mit den Original-Tags brauchen, alle anderen werden das vorverarbeiten. Wozu "highway=residential" als Tag speichern, wenn nur 8 wohldefinierte Tags gebraucht werden?

Insofern bin ich mir nicht sicher, ob das so sinnvoll und machbar ist, was Du vorschlägst.

Gruß
Peter

Am 11.10.2011 10:27, schrieb Nils Faerber:
Hallo!
Ausnahmeweise mal ein TOFU, da der Originaltext nicht weiter zu
kommentieren ist.

Ich habe zwei Softwaretechnische Anliegen, die im Rahmen von OSM
sicherlich auch sehr gut aufgehoben wären und IMHO besser als bisher
organisiert werden könnten/müßten:

1. Effiziente lokale Datenspeicherung und für eine effiziente und
schnelle lokale Abfrage.
Damit meine ich einen allgemeinen Software(-stack) der es ermöglicht,
möglichst effizient auf eine möglichst effizient gespeicherte lokale
Datenbasis zuzugreifen. Die Installation von PostgreSQL+PostGIS ist
nicht sonderlich universell oder effizient - sowohl PostGreSQL als auch
die entstehende Datenbank ist zu resourcenhungrig. Für eine
Tile-Rendering Anwendung auf einem Server ist das kein Problem, aber für
einen kompakten, womöglich mobilen, Client schon.
Es gibt dazu diverse Ansätze in diversen Projekten, doch alle entweder
sehr speziell oder noch nicht sonderlich ausgereift (Spatialite, Navit,
GOSmore etc.). Es wäre sehr nützlich, wenn es hier eine konzierte Aktion
von Seiten OSM gäbe, die dann wiederum als eine Art "OSM quasi standard
API" von Programmen wie Navit etc. benutzt werden könnte.

2. Effizienter und "state-of-the-art" lokaler Map Renderer.
Auch in Zeiten von schnellem mobilem Internet ist es sehr oft nötig,
Kartendaten dennoch lokal zu rendern - sei es, weil gerade keine
Verbindung zum Download von Tiles besteht oder weil eine bestimmte
Ansicht, die nicht als Tiles fertig existiert, dargestellt werden soll.
Das ganze ist natürlich etwas schwierig allgemein zu halten, da die
Zielplattformen nicht genau klar sind und man mit Rendering schnell im
Bereich GUI ist. Es gibt da auch ein paar nette Ansätze, aber alle mit
Haken und Ösen. Ein guter GUI-Subset könnte vielleicht mit Cairo zu
erzielen sein.


Warum das Ganze?
Ich sehe zur Zeit, daß wir zwar mit OSM eine geniale Datenbasis haben,
aber einen großen Teil der möglichen Anwendungen damit nicht abdecken
können, nämlich den mobilen Bereich. Alleine das es bis heute noch keine
sinnvolle "Navi" Software auf Basis von OSM gibt, zeigt meiner Meinung
nach schon die ganze Misere. Und das beginnt, denke ich, mit den
Grundlagen, wie den oben beschriebenen.

Ich arbeite im mobilen Linux Bereich und was ich mir bspw. wünschen
würde, wäre eben eine effiziente und kompakte lokale OSM Datenbank die
ich in mein mobiles Gerät packen kann (und dort nur in etwa soviel
Speicher belegt, wie dies kommerzielle Navis tun). Oben drauf dann im
ersten Schritt ein simples GUI, was die Kartendaten darstellt und den
oben beschriebenen Renderer dazu verwendet. Der eigene lokale Renderer
erlaubt dann auch Spielereien wie einstellbaren Detailgrad, Ausrichtung
der Karte nach Bewegungsrichtung (mit korrekter
Beschriftungsausrichtung), die typische "3D Ansicht" etc. was alles mit
Tile-Downloads nur schwer bis gar nicht möglich wäre.

Ist das geschafft, ist der Weg zu einer Navi Software nicht mehr weit.
Und da wir die Grundlagen (Datenbank, Renderer) allgemein gehalten
haben, könnte es dann von diesen Navi-Softwares dann auch schnell und
einfach eine ganze Reihe geben - wie sagt man auf Neudeutsch, das "heavy
lifting" ist ja dann schon unten drunter gelöst. Ggf. könnte man zu
diesem OSM Client Framework (so könnte man es vielleicht nennen) auch
noch eine Routing-Komponente hinzufügen - dann wäre es wirklich nur noch
ein Anflanschen eines GUIs und wir hätten sehr schnell OSM Navi Software
für Maemo, MeeGo, Tizen, Bada (?), Android, WebOS und natürlich auch für
"normales" Linux mit KDE/GNOME/XFCE/etc. Und das ganze auf einer Basis,
die dann gemeinsam weiter entwickelt und verbessert werden kann, sodaß
deren Verbesserungen gleich allen "angeschlossenen" Applikationen zu
Gute kommt.

Soweit mein Traum... :)

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...


Viele Grüße
   nils



Am 11.10.2011 03:11, schrieb Kai Krueger:
Hallo allerseits,

Openstreetmap ist natuerlich vorwiegend ein mapping Projekt, aber die
Software darum herum ist schon auch irgendwie wichtig, unter anderem  um
OpenStreetMap.org am laufen zu halten, das Leben der Mapper durch
bessere Editoren und QA tools zu erleichtern oder einfach um aus einem
Haufen Rohdaten nuetzliche Sachen zu basteln.

Im Laufe der letzen Jahre ist bereits ein ziemlich beeindruckendes
Software Oekosystem um OSM entstanden, aber dennoch gibt es viele gute
und wichtige Ideen, die bislang nicht umgesetzt wurden, oder nuetzliche
Programme die nicht mehr maintained werden da es oft nicht genug
Entwickler gibt.

Die Frage ist nun was kann man machen um mehr Entwickler fuer
OpenStreetMap zu begeistern und die Entwickler unter uns in der
Community davon zu ueberzeugen sich in Projekte einzubeziehen und
patches zu schreiben z.B. um lang vermisste Funktionen zu ergaenzen oder
Bugs zu beheben.

Um dieser Frage nachzugehen haben sich ein paar Devs vor ein paar Wochen
unter dem Schirm der Engineering Working Group (EWG) zusammen getan um
zu schauen ob wir etwas tun koennen um den Einstieg in die OpenStreetMap
Entwicklung zu erleichtern und mehr Leute dafuer begeistern koennen.
Vorwiegend ist das Ziel mehr Leute fuer die Core Projekte zu begeistern
wie z.B. Potlatch, den rails_port, xapi, nominatim, cgi_map oder anderen
Projekten die derzeit auf den OSMF servern laufen, aber Dinge die die
generelle Entwicklung von OSM basierter Software verbessern oder
erleichtern koennen natuerlich auch Thema sein.

Ein paar der Ueberlegungen die bislang angestellt wurden sind z.B. die
Installationsdokumentation des rails_port zu verbessern, Virtuelle
Machines mit allen noetigen Entwicklungstools und Softwaredependencies
anzubieten, die Verwendung des dev-servers zu verbessern, oder hack
weekends zu organisieren um Leute in Person beim Einstig zu helfen.

Nun kann man aber lange darueber philosophieren was moegliche Gruende
sind das nicht mehr Entwickler sich an diesen Projekten beteiligen,
vielleicht einfacher ist es aber einfach euch zu fragen:

Was wuerde euch motivieren patches zu schreiben? Was euch den Einstieg
erleichtern? Wo liegen derzeit die groessten Huerden um sich zu
beteiligen? Gibt es Dinge die das Leben einem erleichtern wuerde? Was
wuerde diejenigen die bereits viele Patches geschrieben haben helfen
noch mehr patches zu submitten?

Wenn ihr zu diesen Themen Ideen, Anregungen, Vorschlaege oder Kommentare
habt, schreibt sie hier nieder und ich werde sie dann in die EWG
einbringen um zu sehen was man davon umsetzen kann.




Natuerlich sind auch alle herzlich Willkomen sich direkt an der
Engineering Working Group (
http://www.osmfoundation.org/wiki/Engineering_Working_Group )  selbst zu
beteiligen, denn auch dort gilt das uebliche do-ocracy Prinzip. Sie
trifft sich jeden Montag um 17:00 GMT (19:00 deutsche Sommerzeit) auf
IRC unter #osm-ewg (Internet Relay Chat, auf dem OFTC server). Es ist
insgesamt sehr informell. Logs der bisherigen Meetings gibt es unter
http://www.osmfoundation.org/wiki/Working_Group_Minutes#Engineering_Working_Group


Kai




_______________________________________________
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Antwort per Email an