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

[Peter Wendorff]

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