XML-Ecke

Struktur in den Content!

Karten mit GeoJSON gestalten

Es müssen nicht immer Google Maps sein – mit Hilfe des jQuery Geo Plugins lassen sich auch OpenStreetMap-Karten mit wenigen Code-Zeilen auf eine Webseite bringen.

Dazu wird zunächst der Platz für die Karte in einem div-Bereich eingerichtet:

<div id="map" style="width: 640px; height: 480px;"></div>

Anschließend werden zwei Skripte aufgerufen, jQuery selbst und dann das Geo-Plugin:

<script src="http://code.jquery.com/jquery-1.9.1.min.js"></script>
<script src="http://code.jquerygeo.com/jquery.geo-1.0.0-b1.5.min.js"></script>

Und schließlich wird mit einem Schnipsel Javascript die Funktion des Plugins aufgerufen, um die Karte in dem mit “map” bezeichneten div-Bereich zu zeichnen:

?View Code JAVASCRIPT
<script>
  $(function() {
    $( "#map" ).geomap({
		center: [ 8.224425, 49.983942, ],
		zoom: 14
	}); 
  });
</script>

Die Karte wird hier mit einem GeoJSON-Objekt zentriert, wobei anders als sonst üblich zuerst die geographische Länge, dann die Breite angegeben wird. GeoJSON ist ein offenes Format für die Beschreibung geographischer Objekte wie Orte, Strecken oder Flächen. Die Bestimmung einzelner Orte wie hier für die Zentrierung einer Karte richtet sich nach dem Abschnitt “Positionen” der GeoJSON-Spezifikation.

Das Plugin stellt eine Methode “append” bereit, mit der sich GeoJSON-Objekte auf der Karte platzieren lassen, als Punkte, Linien oder Flächen (Polygone). Mit einem Array lassen sich auch mehrere solcher Objekte auf der Karte darstellen. Hier wird die Lage für das Stadion von Mainz 05 mit einem Punkt markiert. Dazu wird die Karte zunächst als Variable definiert, der dann die Methode “append” mit dem GeoJSON-Objekt übergeben wird:

?View Code JAVASCRIPT
<script>
var map = $("#map").geomap({
    center: [8.224425,49.983942],
    zoom: 14})
	map.geomap( "append", { type: "Point", coordinates: [ 8.224425,49.983942 ] } )
</script>

Der Punkt lässt sich auch interaktiv erweitern, wenn man ihn mit einem Popup-Label ergänzt. Der Code für das Beispiel oben ist dann ein klein wenig umfangreicher (zum Aufklappen auf den Pfeil rechts klicken):

?View Code JAVASCRIPT
var popup = null; //< stored reference to our popup shape
 
// create a map, setting mode to drawPoint
var map = $("#map").geomap({
    center: [8.224425,49.983942],
    zoom: 14,
    mode: "drawPoint",
    shape: function(e, geo) {
        // remove any previous popup
        if (popup) {
            map.geomap("remove", popup);
            popup = null;
        }
 
        // search for shapes at the clicked location
        var foundShapes = map.geomap("find", geo, 8);
 
		// find returns an array of 0 or more shapes, do we have a shape?        
        if (foundShapes.length > 0) {
            // create a reference to the click point for the popup label
            popup = geo;
 
            // append the popup shape with appropriate label
            // width & hight are set to 0 because the popup shape is only for position
            // and should not be visible
            map.geomap("append", popup, {
                width: 0,
                height: 0,
            }, foundShapes[0].properties.loc);
        }
    }
});
 
// append a GeoJSON Feature object to also store properties
map.geomap("append", {
    type: "Feature",
    geometry: {
        type: "Point",
        coordinates: [8.224425,49.983942]
    },
    properties: {
        loc: "Mainz 05"
    }
});
</script>
Posted in Im Lauf der Zeit | Tagged , , | Leave a comment

Von der Website zur Web App

Web App im Firefox OS Simulator

Web App im Firefox OS Simulator

Mozilla hat ein Mantra: Wer eine Website gestalten kann, ist auch ein App-Entwickler. Das Open-Source-Projekt will so auch das mobile Web wieder offen machen, es aus den “walled gardens” der Android- und iOS-Welten herausführen. Dieser Blog Post will Anspruch und Wirklichkeit miteinander vergleichen.

Für Apps mit hohen Anforderungen an die Prozessorleistung sind die nativen Apps für ein bestimmtes mobiles Betriebssystem zurzeit noch deutlich leistungsfähiger. Viele Apps aber bereiten lediglich Informationen für die Nutzung auf mobilen Geräten auf – Informationen, wie sie von Websites bislang meist für die Verwendung im Browser und auf Desktop-Geräten bereitgestellt werden. Solche Angebote lassen sich sinnvoll auch als Web-App bereitstellen. Der Vorteil gegenüber der Darstellung im mobilen Browser: Die App kann direkt auf Smartphone-Funktionen wie Kamera oder Geolokalisierung zugreifen und für die Anwendung nutzbar machen.

Das Mozilla-Projekt hat einen relativ einfachen Workflow für die Entwicklung von Web Apps eingerichtet. Eine zentrale Rolle spielt dabei eine einfache JSON-Datei – das Datenaustauschformat der JavaScript Object Notation stellt ähnlich wie XML strukturierte Daten für die Nutzung von Webanwendungen bereit. Bei einer Web-App heißt das App Manifest. Diese JSON-Datei wird mit der Endung .webapp abgespeichert und enthält einige zentrale Daten der App:

{
  "name": "meine App",
  "description": "bei meiner App geht es um das hier...",
  "launch_path": "/index.html",
  "icons": {
    "60": "/images/icon-60.png",
    "64": "/images/icon-64.png",
    "128": "/images/icon-128.png"
  },
  "developer": {
    "name": "mein name",
    "url": "http://meine_website.de"
  },
  "default_locale": "de"
}

Wichtig ist der vollständige Pfad zur Datei mit dem Einstieg zu den Inhalten der Web-Anwendung – es genügt nicht, hier nur das Root-Verzeichnis anzugeben, wie es im Mozilla-Dokument zum Web Manifest angegeben ist.

Das App Manifest von Mozilla ähnelt dem Manifest der Google Extensions, das ebenfalls elementare Daten einer Webanwendung im JSON-Format festhält. Wünschenswert wäre da eine baldige Standardisierung.

Das App Manifest wird auf den Server hochgeladen, ins gleiche Verzeichnis, in dem auch die Daten der Website liegen. Da das App Manifest im Root-Verzeichnis der Website liegt, kann angenommen werden, dass beide vom gleichen Web-Entwickler stammen, was die Sicherheit erhöhen soll. Die App will mit einem Icon auf dem Smartphone-Desktop gestartet werden – mit Blick auf unterschiedliche Systeme kann man hier png-Bildchen in verschiedenen Auflösungen gestalten und im Web Manifest angeben. Eine Anleitung dazu gibt es auch von Mozilla.

Schließlich muss auf dem Server noch eine .htaccess-Datei erstellt oder ergänzt werden, damit der Browser weiß, was er mit dieser merkwürdigen Datei mit der Endung webapp anfangen soll:

AddType application/x-web-app-manifest+json .webapp

Nun kann das App Manifest in einem Validator überprüft werden. Wenn bei dieser Prüfung keine Fehler beanstandet werden, ist die Entwicklung der Web App theoretisch schon abgeschlossen:

Der Firefox OS Validator testet das Web Manifest

Der Firefox OS Validator testet das Web Manifest

Die Web-App soll ähnlich wie eine native App bedient werden, also auf dem mobilen Gerät nicht im Browser-Fenster erscheinen, sondern als eigenständige Anwendung. Dafür sorgt die Web Runtime von Mozilla. Die Funktionen dieser API können entweder in den HTML-Code der beim Start aufgerufenen Webseite eingefügt werden – oder der Web-Designer überlässt das einer Plattform wie Github oder dem Firefox Marketplace. Die Web Runtime installiert das Icon auf den Desktop des Betriebssystems, startet von dort aus die App in einem rahmenlosen Fenster und sorgt dafür, dass Hardware-Funktionen wie die Kamera von der App adressiert werden können. Die Web Runtime ist Bestandteil der Browser-Rendering-Technik Gecko und soll in einer künftigen Version des Firefox-Browsers mit integriert werden.

Damit die App auf Funktionen des Smartphones zugreifen kann, hat Mozilla eine WebAPI bereitgestellt: Dazu gehören eine Vielzahl von JavaScript-Funktionen wie der Zugriff auf Uhrzeit, Geolokalisierung oder Kontakte. Für die volle Einbindung der App ins Smartphone gibt es außerdem die WebActivities – hier fordert die App vom Anwender eine Entscheidung zur ergänzenden Nutzung einer anderen App. Zum Beispiel will die WebActivity “pick” ein Foto haben – der Anwender kann nun entscheiden, ob er ein Foto aus der Sammlung gespeicherter Bilder nimmt oder mit der Kamera ein neues Foto aufnimmt. Um etwa die Geodaten vom Smartphone auszulesen, ruft eine JavaScript-Anweisung die Methode getCurrentPosition() auf, was nur wenige Codezeilen erfordert:

?View Code JAVASCRIPT
var geolocation = document.querySelector("#geolocation"),
            geolocationDisplay = document.querySelector("#geolocation-display");
        if (geolocation && geolocationDisplay) {
            geolocation.onclick = function () {
                navigator.geolocation.getCurrentPosition(function (position) {
                    geolocationDisplay.innerHTML = "<strong>Latitude:</strong> " + position.coords.latitude + ", <strong>Longitude:</strong> " + position.coords.longitude;
                    geolocationDisplay.style.display = "block";
                },
                function (position) {
                    geolocationDisplay.innerHTML = "Failed to get your current location";
                    geolocationDisplay.style.display = "block";
                });
            };
        }

Für die Offline-Nutzung einer Web App kann ein AppCache in die index.html eingebunden werden. Ein Cache Manifest listet die URLs der Dateien auf, die offline bereitgestellt werden sollen. Diese Technik nutzt die Fähigkeiten von HTML5 für das Application Caching.

Das Verhalten der App im Firefox OS von Mozilla kann man im Firefox-Browser mit Hilfe eines Simulators testen. Dieses virtuelle Firefox-Smartphone muss zunächst mit der Maus “entriegelt” werden: Dazu schiebt man den Pfeil nach oben und klickt dann rechts auf das Schloss-Symbol. Mit gedrückter Maustaste kann man nun zwischen den verschiedenen Desktops hin und her blättern und einige der installierten Apps starten. Wenn man dem Simulator die URL der Datei mit dem Web Manifest mitgeteilt hat, wird auch diese App installiert und kann nun in ihrem Verhalten getestet werden.

Dabei zeigt sich, dass der Weg von der Website zur Web App in der Praxis doch etwas länger ist als zunächst gedacht. Beim Versuch, meine mit Joomla 2.5 gestaltete Website www.miramis.de zur App zu machen, zeigt sich, dass sich diese nicht automatisch an das mobile Display anpasst – obwohl ich dafür ein responsives Template nutze. Auf einem iPhone oder einem Android-Smartphone wird so dafür gesorgt, dass die Darstellung der Joomla-Website optimal an das mobile Display angepasst wird. Dieselbe Website in Verbindung mit einem Web Manifest wird im Firefox OS Simulator aber in der großen Desktop-Auflösung dargestellt. Hier ist also die Nutzung eines mobilen Frameworks wie JQuery mobile der sinnvollere Weg – wie das dann im Firefox OS Simulator aussieht, zeigt der Screenshot ganz oben.

Mit JQuery mobile entwickelte Web-Anwendungen unterstützen denn auch die ganze Vielfalt von mobilen Plattformen – von Android über iOS bis Blackberry 10 und Windows Phone. Eine Web App für Firefox OS aber kann das Versprechen einer plattformübergreifenden Nutzung bislang noch nicht einlösen: Sie kann zurzeit nur mit Firefox OS, mit dem Firefox-Browser für Android und mit Firefox-Testversionen Nightly und Aurora gestartet werden. Der Ansatz von Mozilla ist interessant und zukunftsfähig. So hoffe ich, dass er in diesem Jahr zügig weiterentwickelt wird – in Richtung Standardisierung beim Web Manifest und in Richtung einer breiten Plattformunterstützung im Sinne eines rundum offenen Webs.

Posted in Im Lauf der Zeit | Tagged , , , , | Leave a comment

IPTC treibt Entwicklung von rNews voran

Mit dem neuen Projekt schema.org kommt langsam Bewegung ins semantische Web. Da passt es, dass auch der International Press Telecommunications Council (IPTC) die Entwicklung seines neuen Standards rNews vorantreibt. Auf einem Arbeitstreffen in Berlin billigte die Organisation die Version 0.5 des Standards, der erst im April  vorgestellt wurde. Die “draft version” berücksichtigt die Erfahrungen aus den ersten Tests zur Umsetzung von rNews.

Das Markup von rNews, so erklärte Stuart Myles während der Beratungen in Berlin, bemühe sich um einen ausgewogenen Kompromiss zwischen einer möglichst einfachen Anwendung ohne tiefgreifende Änderungen an bestehenden HTML-Dokumenten und einer einfachen Nutzung ohne komplizierte Software-Werkzeuge zum Parsen, also zur Syntaxanalyse von rNews. Die Änderungen machen das Modell eingängiger und einfacher. So wird nun nicht mehr von “Tags”, sondern von “Concepts” gesprochen – als Basisklasse für Angaben zum Inhalt von Nachrichten . Die zunächst als eigene Klasse festgelegten Angaben zur Überschrift mit der Bezeichnung “Hed” wurden unter den Eigenschaften der Klasse NewsItem subsumiert. Und die bisherige Klasse TickerSymbol wurde nun zu den Eigenschaften von Organization gestellt.

Der IPTC will auch Möglichkeiten für das Mapping, für die Transformation von rNews in andere Formate anbieten, darunter HTML5-Mikrodaten und JSON. Für Verleger soll es damit so einfach wie möglich gemacht werden, rNews in bestehende Workflows einzubinden. “rNews erschließt den Wert der Veröffentlichung von Metadaten bei Online-News, indem es dafür einen einfach zu verwenden Standard bereitstellt, der ausschließlich Web-Technologien verwendet”, erklärte Myles, der die Arbeitsgruppe Semantisches Web beim IPTC leitet und sich bei Associated Press um Nachrichtenformate kümmert. Bis zum nächsten IPTC-Treffen im Oktober soll rNews die Entwurfsphase hinter sich lassen und in der Version 1.0 vorgelegt werden.

Die vom IPTC gepflegten XML-Formate NewsML oder NITF sind vor allem dazu gedacht, Nachrichten-Feeds in die Content-Management-Systeme der Medienunternehmen zu bringen. Diese können den aktuellen Content dann als HTML-Dokumente mit semantischen Metadaten in ihre Web-Angebote bringen. Ob dabei rNews, das schlichtere Mikroformat hNews oder eine künftige Lösung im Rahmen des Suchmaschinen-Projekts schema.org zum bestimmenden Standard werden wird, entscheiden vermutlich nicht zuletzt auch wirtschaftliche Interessen im Spannungsfeld zwischen Medienunternehmen und Suchmaschinen-Betreibern.

Posted in Im Lauf der Zeit | Tagged , , , | Leave a comment

Google vereinfacht Geocoding-Service

Rund zehn Monate nach der Einführung von Version 3 (V3) der Google Maps API hat Google auch seinen Geocoding-Service vereinfacht, der Postadressen oder Ortsangaben in Geodaten umwandelt. Auch hier ist jetzt kein besonderer Key für die Nutzung des Dienstes mehr erforderlich. Es genügt die Anforderung beim Webservice nach dem Schema:

http://maps.google.com/maps/api/geocode/output?parameters

Der Platzhalter “output” wird ersetzt durch Angaben zum gewünschten Ausgabeformat, wobei XML oder das schlanke JSON zur Verfügung stehen. Statt “parameters” wird die gewünschte Adresse angegeben, also zum Beispiel:

http://maps.google.com/maps/api/geocode/xml?address=Weifert-Janz-Straße+1+Mainz&sensor=false

Der erforderliche Parameter “sensor” gibt an, ob die Anfrage von einem Gerät mit der Erfassung von Geodaten kommt oder nicht. Optional kann mit dem Parameter “region” die geografische Region eingegrenzt werden, was etwa bei Orten sinnvoll ist, die es in mehreren Ländern gibt. Ohne diese Differenzierung zeigt der Geocoder zum Beispiel bei der Abfrage von Toledo den im US-Staat Ohio gelegenen Ort an. Erst die Präzisierung mit “region=es” sucht nach der spanischen Stadt. Für die Bezeichnung der Region werden die Länder-Codes der Top-Level-Domains (ccTLD) verwendet, also etwa “de” für Deutschland. Das Ergebnis der Abfrage im JSON-Format führt alle bekannten Informationen auf, darunter auch die Geodaten der geografischen Länge und Breite:

{
  "status": "OK",
  "results": [ {
    "types": [ "street_address" ],
    "formatted_address": "Weifert-Janz-Straße 1, 55122 Mainz, Deutschland",
    "address_components": [ {
      "long_name": "1",
      "short_name": "1",
      "types": [ "street_number" ]
    }, {
      "long_name": "Weifert-Janz-Straße",
      "short_name": "Weifert-Janz-Straße",
      "types": [ "route" ]
    }, {
      "long_name": "Mainz",
      "short_name": "Mainz",
      "types": [ "locality", "political" ]
    }, {
      "long_name": "Mainz",
      "short_name": "MZ",
      "types": [ "administrative_area_level_2", "political" ]
    }, {
      "long_name": "Rheinland-Pfalz",
      "short_name": "RP",
      "types": [ "administrative_area_level_1", "political" ]
    }, {
      "long_name": "Deutschland",
      "short_name": "DE",
      "types": [ "country", "political" ]
    }, {
      "long_name": "55122",
      "short_name": "55122",
      "types": [ "postal_code" ]
    } ],
    "geometry": {
      "location": {
        "lat": 50.0042904,
        "lng": 8.2410587
      },
      "location_type": "RANGE_INTERPOLATED",
      "viewport": {
        "southwest": {
          "lat": 50.0011490,
          "lng": 8.2379114
        },
        "northeast": {
          "lat": 50.0074443,
          "lng": 8.2442067
        }
      },
      "bounds": {
        "southwest": {
          "lat": 50.0042904,
          "lng": 8.2410587
        },
        "northeast": {
          "lat": 50.0043029,
          "lng": 8.2410594
        }
      }
    }
  } ]
}

Die JSON-Elemente lassen sich nun mit wenigen Codezeilen als Javascript-Variablen definieren und für Kartendarstellungen verwenden – zum Beispiel:

?View Code JAVASCRIPT
var latitude = myJSONResult.results.location.lat;
var longitude = myJSONResults.location.lng;

Dabei verlangt Google in seinen Nutzungsbestimmungen, dass nur Karten auf der Grundlage seiner eigenen APIs für Google Maps oder Google Earth verwendet werden dürfen. Neben der Auflösung von Adressen wird auch das Reverse Geocoding unterstützt, also die Umwandlung von Geodaten mit den Angaben der geografischen Breiten- und Längengrade in Adressen. Für das oben gezeigte Beispiel funktioniert dies etwa auf diese Weise:

http://maps.google.com/maps/api/geocode/json?latlng=50.0042904,8.2410587&sensor=false
Posted in Im Lauf der Zeit | Tagged , , | Leave a comment