OSMPOI4Layar - Webserver für den AR-Browser Layar mit POI-Daten von OpenStreetMap
Idee: Entwicklung eines Servers, der OpenStreetMap-POIs mit Höhe ergänzt und als Ebene (= Layer) in Layar anbietet. Jeder POI wird dann mit ID (z.B. Fäschtinseli), falls vorhanden Name ("Fäschtinseli"), die Tags ("fireplace = yes, tourism = picnic_site") und Weblink (z.B. Tag 'website' HSR) angezeigt.
Hinweise:
Erwartete Resultate:
Themenwahl
Definitive Wahl treffen.
Konzept ueberlegen und zurecht finden auf virtuellen Maschine.
Eventuell mit Ruby on Rails 3 ein Proof of Concept machen, um zu sehen, ob das tatsaechlich funktioniert. Ich denke, der Aufwand dafuer ist ziemlich klein.
Erster Entwurf des Java-Codes. Bis dahin muss ich zuerst herausfinden, wie man so etwas in Java macht. JSP? J2EE? Was fuer existierende Libaries gibt's, die nuetzlich waeren? Als Layar-Layer publizieren.
Java-Code verfeinern und besprechen mit Betreuer.
Code programmieren, um die fehlende Hoehenangabe (vom Layar-Browser oder der POIs in der Datenbank?) zu errechnen.
Eventuell die XAPI von osm.xiala.net zur POI-Abfrage benutzen.
Einen genaureren Blick auf das .pbf-Format werfen und ueberlegen, ob es Sinn macht, dies zu parsen und in einer eigenen Datenbank abzulegen.
Reserve.
Reserve.
Praesentation als Keynote vorbereiten.
Kurzpräsentation
Die Java-Applikation laeuft serverseitig und kann den einzigen, von Layar definierten HTTP-Request (RESTful) entgegen nehmen. Dieser heisst "GetPOIs". Alle relevanten Informationen werden aus dem Query-String geparsed (eventuell mit Hilfe einer entsprechenden Java-Library). Die Applikation fragt dann die PostgreSQL-Datenbank mit den POIs aus OSM mit einem vorbereiteten SQL-Query ab. Alle gefundenen POIs werden dann in eine JSON-Response gepackt (eventuell mit Hilfe einer entsprechenden Java-Library) und als Antwort auf den HTTP-Request zurueckgesendet.
Layar schreibt voraus, dass alles UTF-8 sein muss und, soweit ich weiss, sind alle Strings in Java als UTF-16 hinterlegt. Aber dies kann man sicher irgendwie umwandeln.
Aufklaerung ueber das Miniprojekt. Aufgabe scheint pwenger ueberschaubar.
Layar scheint eine faszinierende Software zu sein. Der Layar-Browser ist jetzt auf meinem iPhone installiert. Der GetPOIs-Request und die JSON-Response von Layar scheinen einleuchtend.
Die Registration bei OpenStreetMap ist erfolgt und ich bereits in meiner Umgebung einige Points gesetzt, um es ein Wenig kennen zu lernen.
Der virtuelle Server funktioniert. Java und Ruby sind installiert. Ich werde mit dem Konto "student" arbeiten.
Ich habe mich informiert ueber die Java Servlets und die scheinen perfekt zu sein. Genau genommen ist es das HttpServlet, welches mir sehr zusagt.
Totale Blockierung, da das Package "javax" nicht gefunden wurde.
Das "javax"-Package wird mit Hilfe der "servlet-api.jar"-Datei der Tomcat-Distribution endlich erkannt. Ich habe herausgefunden, dass Jetty 7 nur die "Dynamic Web Module"-Version 2.5 unterstuetzt, ich in Eclipse fuer das Projekt aber 3.0 gewaehlt habe. Aus dem selben Grund funktionierte auch die "servlet-api.jar"-Datei aus der Jetty-Distribution nicht.
Das Projekt habe ich dann neu initialisiert mit Zielversion 2.5. Jetty wurde dann als Targetserver sichtbar, jedoch Startprobleme. Mit Tomcat 6 und anfaenglichen Startschwierigkeiten funktionierte es lokal auf dem Mac. Das Projekt als WAR-Datei exportiert, auf den virtuellen Server kopiert, funktioniert sogar das Hotdeployment im Tomcat auf dem virtuellen Server. Siehe http://sinv-56014.edu.hsr.ch:8080/OSMPOIs4Layar/GetPOIs.
Das Projekt ist jetzt auf Github unter meinem Account: https://github.com/paddor/OSMPOIs4Layar. Die Datenbanklogininformationen werden in einer dedizierten Klasse als static fields zur Verfuegung gestellt. Die Datei dafuer ist nicht in Git eingecheckt und wird ignoriert per ".gitignore"-Datei.
Die Datenbankverbindung konnte noch nicht aufgebaut werden, da der PostgreSQL-Treiber nicht gefunden wurde, obwohl ich die entsprechende JAR-Datei ins "lib"-Verzeichnis importiert habe und die JAR-Datei auch aktiviert habe. Ich musste die JAR-Datei auch noch explizit als Abhaengigkeit ("dependency") markieren, damit sie auch in die WAR-Datei exportiert wurde. Die Verbindung zur Datenbank laesst sich aber immer noch nicht aufbauen, da der PostgreSQL-Server nicht erreichbar ist. Die IP-Adresse ist zwar pingbar, jedoch scheint der PostgreSQL-Server zumindest von der virtuellen Maschine aus nicht zu antworten. Lokal vom Mac aus funktioniert's mit dem "psql"-Befehl und auch mit der OSMPOIs4Layar-Applikation. Da muss irgend eine Firewall-Regel fuer den virtuellen Server geaendert/hinzugefuegt werden.
Ueber Orux habe ich mich informiert. Ich konnte keine Erwaehnung von Layar finden. Eventuell haben die "Offline layered maps" Sie getaeuscht?
Die Umgebung auf der virtuellen Maschine habe ich meinen Wuenschen angepasst.
Die Syntax dieses Wikis ist mir jetzt bekannt. Leider gibt es keine moeglichkeit, eine fixed-width Schriftart inline zu verwenden, so wie es angenehm fuer Dateinamen oder Variablennamen im Fliesstext waere.
Die POIs aus der Datenbank werden jetzt direkt als echte Point-Objekte geladen. Dies sollte die spaetere Erstellung der JSON-Response vereinfachen, da dort die Koordinatenkomponenten jeweils einzeln benoetigt werden.
Seit Montag, dem 7. November 2011 sollte der Port vom virtuellen Server auf den Datenbankserver geoeffnet sein.
Fuer das Parsen des Requests habe ich eine Klasse ch.hsr.OSMPOIs4Layar.RequestParser geschrieben. Sie hat die Methode #parse und gibt die geparsten Dinge als Hashmap<String, Object> zurueck. Im Fall eines fehlerhaften Request wird eine IllegalArgumentException geworfen.
ch.hsr.OSMPOIs4Layar.RequestParser heisst jetzt ch.hsr.OSMPOIs4Layar.GetPOIsRequest und enthaelt die einzelnen Angaben aus dem Request als Fields. Die Methode #parse ist jetzt privat und wird vom Konstruktor aufgerufen.
Die Angaben aus dem Request werden jetzt fuer die Suche in der Datenbank verwendet. Beruecksichtigt werden folgende Angaben: Position (lat und lon), gewuenschter Radius und die Genauigkeit der Ortsbestimmung (accuracy).
Nur gedanklich an diesem Projekt gearbeitet.
Nur gedanklich an diesem Projekt gearbeitet.
Es wird jetzt mit JSON geantwortet. Alle obligatorischen Felder werden unterstuetzt. Das feld "id" wird sogar durch den #hashCode mehrerer Fields errechnet.
Die neue Version der Applikation ist deployed auf dem virtuellen Server, jedoch schein der Port 8080 vom Internet auf den virtuellen Server geblockt oder falsch weitergeleitet zu sein. Jeglicher Versuch ueber's Internet endet im Timeout. Lokal auf dem virtuellen Server funktioniert es.
Das SVN-Repository von PostGIS habe ich geklont. Damit waere ich also bereit fuer 9.1 und PostGIS 2.0. Momentan ist auf dem virtuellen Server PostgreSQL 8.4.9 installiert.
Ich habe vieles zu Ruby/GIS/GEOS/(Geo)TIFF/GDAL gelesen. Folgende Projekte toenen nuetzlich:
Auch habe ich mich auf http://www.gdem.aster.ersdac.or.jp registriert und probierte, wenigstens zwei Kacheln des Evelation Models herunterzuladen. Jedoch hat dies nicht geklappt. Angeblich schlug der Zugriff auf den Server fehl. :-(
Nur gedanklich und verbal an diesem Projekt gearbeitet.
Praesentation wurde gehalten am Mittwoch Vormittag. Danach fand ich nochmals Zeit, um einiges zu verbessern. Im Apache Webserver habe ich einen Reverse-Proxy eingerichtet, damit Tomcat wieder von aussen erreichbar ist. Fehler in der JSON-Response wurden behoben. Zusaetzlich wird jetzt nebst dem Titel (osm_pois.name) auch eine Beschreibung (osm_pois.tags) ausgelesen und in die JSON-Response gepackt.
Man kann jetzt nach einem Teilstring des POI-Namen suchen und auch nach dem exakten OSM-User, der den POI erstellt hat, filtern.
Die fehlerhafte Konvertierung von Unicode in ein Latin-Charset durch HttpServlet wurde behoben.
Dies alles kann webbasiert in der von Layar bereitgestellten Testumgebung bereits visualisiert werden. Siehe http://www.layar.com/publishing/testpage/page/osmpois/# Die Koordinaten der HSR sind in etwa: 47.22300742955065, 8.819189071655273
SQL-Injection muss noch verhindert werden! Da mein Query optionale Suchfelder miteinbeziehen muss, kann ich das schlecht mit prepared Statements machen, ausser ich definiere 4 von ihnen (eins fuer jeden moeglichen Fall). Eigentlich wuerde ich lieber die Funktion, welche die Strings SQL-safe macht, selbst verwenden. Diese kann ich aber nicht finden in der API-Dokumentation von java.sql.*
Ansonsten steht der Veroeffentlichung eigentlich nichts mehr im Wege.