Einträge werden als ‘Meinungen’ kategorisiert
All Points Blog hat in der letzen Woche von einem Forschungsprojekt im Hause Microsoft bericht, das den Namen Eagle 1 trägt und stark an Initiativen des OGC erinnert.
Eagle 1 pulls information from multiple databases and uses geospatial mapping technology to create an interactive map that would show, for example, all the schools, military bases, hospitals in the affected area. Plus it would show how many people are in the hospitals, current evacuation models and casualties or danger zones, even a plume model that could show where a gas leak is heading.
Das ist exakt das, worauf die Interoperabilitätsinitiativen des OGC abzielt: Die integrierte Verarbeitung und Visualisierung von Daten mit geographischen Bezug. Dass es in diese Richtung Aktivitäten gibt ist sicherlich lobenswert, allerdings verstehe ich nicht, wieso diese Arbeit nicht in Initiativen des OGC eingebracht oder zumindest mit dem OGC abgestimmt wird. Und das obwohl Microsoft sogar OGC-Mitglied ist.
Kategorien: Meinungen
Mit Tag(s) versehen: Microsoft, OGC
In dem Beitrag WMS, WFS, and Community Schemas hat sich Ron Lake zu den Interoperabiltätsproblemen derzeitiger Implementierungen der Web Map Service oder Web Feature Service Spezifikation geäßert. Er kritisiert darin, dass nachwievor Schwächen bei der Unterstützung so genannter Community Schemas bestehen. Insbesondere die fehlenden Möglichkeiten zur Abbildung von verschiedenen Datenbankschemas auf ein gemeinsames Community Schema sieht er als großes Problem, das die Datenintegration in einer Geodateninfrastruktur behindert.
Auch die weite Verbreitung so genannter Integrated WMS Architekturen, also Architekturen bei denen Map Service und Datenquelle fest gekoppelt sind, führt er auf dieses Problem zurück. Er fordert daher die Entkopplung von Map Services und den zu visualisierenden Daten, was als Component WMS bekannt ist. Demnach wird im GetMap-Request die URL einer Datenquelle mittels REMOTE übergeben. Der WMS fordert die Daten dann von einem WFS oder WCS durch einen GetFeature oder GetCoverage-Requests an. Ein WMS kann dann also Daten von verschiedenen Datenservices integriert darstellen.
Die Kritik Lakes in Bezug auf die fehlende Unterstützung für Community Schemas ist verständlich, da eine Integration von Daten, die zwar der gleichen thematischen Bereich angehören, allerdings von verschiedenen Anbietern bereit gestellt werden, so nicht möglich ist. Allerdings wird die Component WMS Architektur auch heute schon von verschiedenen Implementierungen (z.B. GeoServer oder MapServer) unterstützt — zumindest für die Visualisierung von Daten eines Web Feature Service. Prinzipiell ist die integrierte Visualisierung von Daten also möglich. Nur die Datenintegration in einem Layer könnte aufgrund unterschiedlicher Datenmodelle problematisch sein. Es handelt sich also hierbei nicht um eine Problem, das auf die Architektur zurück zu führen ist, sondern lediglich auf die fehlende Unterstützung von Community Schemas.
Laut Lake würde eine Component WMS Architektur auch das Problem umgehen, dass keine Möglichkeiten zur Steuerung der Visualisierung von Geodaten bestehen, weil das zu Grunde liegende Datenschema nicht einsehbar ist. Das gilt aber nur dann, wenn der WMS nicht zusätzlich Teile eines WFS-Interfaces bereit stellt. Bei vielen Produkten, z.B. Geoserver oder MapServer, werden neben der WFS-Spezifikation auch WFS oder WCS unterstützt. In dem Fall is es möglich, mit dem DescribeLayer-Request des WMS-Infaces die Basis-URL des zugehörigen WFS zu ermitteln und dann den DescribeFeatureType-Request des WFS-Interfaces zu nutzen, um eine Beschreibung der zu Grunde liegende Datenstruktur zu bekommen. Mit Styled Layer Descriptor kann dann auf dieser Basis vom Client aus die Visualisierung der Daten durch den WMS beeinflusst werden.
Die Implementierung eines WMS als Component Architektur ist nicht immer sinnvoll ist. Denn ein Component WMS, der offen zur Verfügung steht, kann natürlich auch von jedem zur Visualisierung von Daten genutzt werden. Das kann zu erheblichen Traffic und zu erhöhten Kosten für den jeweiligen Anbieter führen. Ob das dann im Sinne des Anbieters ist, ist fraglich. Es müsste also Möglichkeiten geben, die Nutzung solcher Anwendungen nur für bestimmte Nutzer zu erlauben und vielleicht sogar eine Auswahl nutzbarer Datenservices zu definieren.
Lakes Kritikpunkte sind also teilweise nachzuvollziehen, geht aber zum Teil auch einen Schritt zu weit. Denn Coupled WMS Architekturen sind einerseits schon möglich, sind aber andererseits nicht zwangsläufig die perfekte Lösung für jeden Anwendungsfall.
Kategorien: Meinungen · Software
Mit Tag(s) versehen: SLD, WFS, WMS
Geode ist eine Firefox-Extension, die die W3C Geolocation API implementiert und es Webseiten ermöglicht, die aktuelle Position des aufrufenden Benutzers zu bestimmen Darauf aufbauend können die Inhalte entsprechend angepasst werden. In den kommenden Versionen von Firefox wird diese Funktionalität standardmäßig unterstützt werden.
Die Anwendungsszenarien gehen über die üblichen Beispiele von Location Based Services (LBS), wie z.B. ein Restaurant in der Nähe finden, hinaus:
For example, imagine an RSS reader that knows the difference between home and work and automatically changes it’s behavior appropriately. Or a news site whose local section is, in fact, actually local. Or Web site authentication that only allows you to login from certain physical locations, like your house.
Die Privatssphäre wird durch verschiedene Stufen der Informationsfreigabe gewahrt. Der Nutzer kann bestimmem, ob seine exakte Position, die Nachbarschaft oder Stadt, in der er sich momentan befindet, oder ob gar keine Information an den Serviceprovider übermittelt werden soll.
Die Positionsbestimmung hat in manchen Situationen noch Schwächen. Während die Bestimmung meiner exakten Position mit der Beispielanwendung Food Finder sehr gut funktionierte, war die Bestimmung der Stadt, in der ich mich gerade aufhalte eher wenig zufrieden stellend. Da wurde ich ein ganzes Stück außerhalb von Jena platziert.
Trotzdem eine gute Sache, denn bei einer immer größer werdenden Menge von Informationen wird der lokale Kontext eine entscheidende Rolle für die Qualität von Suchergebnissen spielen.
Kategorien: Meinungen · Software
Mit Tag(s) versehen: Browser, Geolocation API, Location Based Service
OpenStreetMap erfreut sich immer größerer Beliebtheit. Die Weltkarte, die nach dem Wiki-Prinzip verwaltet wird, bietet nicht nur freies Kartenmaterial an, sondern zählt aufgrund seiner zahlreichen Mitwirkenden auch zu den aktuellsten derzeit verfügbaren Datensätzen.
Doch die Nutzung dieser Daten in anderen Anwendungen gestaltet sich unter Umständen als schwierig, da die Daten nur in ungewöhnlichen Formaten exportierbar sind und deshalb nicht einfach in andere Anwendungen integrierbar sind.
Um OSM-Daten in beispielsweise einem Desktop-GIS weiterverwenden zu können, müssen die Daten momenten zunächst aus dem proprietären OSM-Format in standardkonforme beziehungsweise deFacto-Standardkonforme Formate (z.B. GML oder Shapefiles) umgewandelt werden. Statt sie z.B. mit XSLT zu transformieren, könnte man die Daten auch unmittelbar verwenden, wenn diese über einen Web Feature Service (WFS) bereit gestellt würden und im GML-Format ohne Umwege in ein GIS importiert werden könnten.
Ebenso können OSM-Karten nicht einfach in einem browser-basierten Client, wie OpenLayers, dargestellt werden. Prinzipiell ist das zwar möglich, indem man eine zusätzliche JavaScript-Bibliothek verwendet. Es ginge aber auch einfacher, wenn man die Daten über einen Web Map Service (WMS)- oder Web Feature Service (WFS) integrieren könnte. Darüber hinaus bestünde dann sogar die Möglichkeit, die Visualisierung an eigene Anforderungen anzupassen, indem man mittels Styled Layer Descriptor (SLD) Visualisierungsregeln an einen Map Service übermittelt.
Natürlich sind die hier aufgeführten Beispiele keine essenziellen Einschränkungen für die Funktion von OpenStreetMap. Aber die Bereitstellung von OSM-Daten über OGC-konforme Webservices würde nicht nur die Art und Weise der Datennutzung vereinfachen, sondern auch deren Reichweite erheblich erhöhen.
Projekte wie der OpenLS Route Service zeigen eindrucksvoll, welche Möglichkeiten für Daten- und Serviceintegration durch den konsequenten Einsatz von Standards entstehen.
Und gerade weil OpenStreetMap ein Paradebeispiel für die Übertragung des Open Source-Gedankens auf die Welt geographischer Daten ist, und somit insbesondere für Offenheit steht, könnte das Projekt auch dazu dienen, für die Vorteile der Nutzung von Standards zu werben.
Kategorien: Daten · Meinungen · Standards
Mit Tag(s) versehen: OGC, OpenStreetMap
FortiusOne, die Frima, die hinter Geocommons steht, hat passend zum Finder!, mit dem man offene Geodaten finden und bereit stellen kann, eine neue Anwendung namens Maker! veröffentlicht.
Wie der Name impliziert kann man mit Maker! thematische Karten erstellen. Grundlage sind dafür die in Geocommons abgelegten Daten.
1: Geocommons Maker! MapBrewer
Im Mittelpunkt steht dabei der so genannte
MapBrewer, ein Wizard, der den Anwender nach Auswahl eines Datensatzes schrittweise bei der Erstellung der Karte hilft. Zunächst wird die zu visualisierende Variable ausgewählt, dann erfolgt die Klassifizierung auf Basis verschiedener statistischer Parameter und schließlich werden Symbole und Farben festgelegt (Fig. 1). MapBrewer ist dabei so einfach angelegt, dass auch Nutzer mit geringen Kartographie- oder Statistikkenntnissen schnell zu guten Ergebnissen kommen. Es besteht außerdem die Möglichkeit, die Klassifizierung später manuell zu verfeinern, was vor allem kartographisch erfahrenen Nutzern entgegen kommen dürfte.
Darüber hinaus bietet Maker mit Straßenkarten, Satellitenbilder und Geländekarten von Google, Microsoft, Yahoo, OpenStreetMap und der NASA eine Fülle von Basislayern zur Auswahl.
2: Kartenanzeige in Google Earth
Die so erstellten Karten können über einen Permalink anderen Usern zugänglich gemacht werden oder als KML exportiert und z.B. in Google Earth angezeigt (Fig. 2) werden.
Wer außerdem eigene Daten in die Anwendung einfügen möchte, der kann diese in den Finder hochladen. Dabei werden Shapefiles, CSV mit Lat/Long-Koordinaten oder KML-Files akzeptiert.
Insgesamt gesehen, ist Maker! ein äußerst nützliches und hervorragend umgesetztes Tool, weil die Anwendung eine einfache und schnelle Erstellung thematischer Karten sowie deren Bereitstellung für Andere ermöglicht, ohne dass man dabei auf umfangreiche GIS-Software zurückgreifen muss.
Weitere Meinungen
Kategorien: Daten · Meinungen · Software
Mit Tag(s) versehen: Webmapping
Die Cartography Research Group der Universität Bonn hat mit dem OpenLS Route Service einen web-basierten Routenplaner implementiert, der frei zugängliche Geodaten von OpenStreetMap verwendet, die darüber hinaus über OGC-konforme Services bereit gestellt werden.
Die Anwendung implementiert eine Reihe von OGC Spezifikationen. Besonders hervorzuheben ist dabei neben der Verwendung der OpenLS Spezifikation die Visualisierung aktueller Verkehrsinformationen, wie Staus und Baustellen, mit Hilfe eines Service Chains zwischen einem Sensor Observation Service, einem Web Processing Service und einem transaktionellem Web Feature Service.
Der Mehrwert von OpenLS Route Service könnte sicher noch erhöht werden, wenn die Straßendaten direkt von OpenStreetMap über einen standardkonformen Service abgerufen werden könnten. OpenStreetMap stellt seine Daten derzeit allerdings nur in einem proprietären Datenformat zur Verfügung, sodass die Daten über einen internen WFS bereit gestellt werden müssen. Dass kann unter umständen die Aktualität der Daten negativ beeinflussen.
Nichtsdestotrotz zeigt die Anwendung sehr gut die Möglichkeiten OGC-konformer Webservices in Verbindung mit Nutzergenerierten Geodaten für ein alltägliches Szenario.
Tiefgründigere Erläuterungen zum OpenLS Route Service können in einem Artikel von Alexander Zipf im Directions Magazine nachgelesen werden.
Kategorien: Daten · Meinungen · Software · Standards
Mit Tag(s) versehen: OGC, OpenStreetMap
Die immer größer werdende Beliebheit von Internetkarten und satellitengestützten Navigationssystemen führt dazu, dass die Menschen nur noch darüber nachdenken, wie sie von A nach B kommen, und niemand mehr über die eigene Position oder die umgebende Geographie bescheid weiß. Das zumindest behauptet die Vorsitzende der British Cartographic Society, Mary Spence.
Sie führt das darauf zurück, dass Karten zur Navigation nicht mehr gelesen werden müssen. Darüber hinaus verstünden Kartennutzer die traditionellen kartographischen Symbbole nicht, da diese nicht in digitalen Karten zu sehen sind.
Das führt nach Spence dazu, dass Britische Geschichte und Geographie aus dem Bewusstsein der Bevölkerung verschwinden:
Corporate cartographers are demolishing thousands of years of history – not to mention Britain’s remarkable geography – at a stroke by not including them on maps which millions of us now use every day [...] — Telegraph
Wie Jonathan Crowe argumentiert liegt das Problem aber weniger darin, dass wir verstärkt computergestütztes Material anstelle der klassischen Papierkarte einsetzen, sondern vielmehr darin, was auf den Karten überhaupt dargestellt wird.
Denn auch im Diercke oder einem Falk-Straßenatlas fanden keine Kirchen oder andere historisch bedeutende Bauten Platz. Solche Sachen waren meist nur auf speziellen Karten, wie der TK25 oder auf Wanderkarte zu finden. Eine thematische Auswahl hat – im Sinne des Kartenzwecks und ihrer Lesbarkeit – immer schon stattgefunden.
Aber gerade dem Anspruch jeden Kartennutzer zu befriedigen, können Internetkarten eher gerecht werden, als gedruckte. Denn nur hier besteht die Möglichkeit, dem Nutzer die Wahl zu lassen, was auf einer Karte zu sehen sein soll. Durch verschiedene Kartenlayer lassen sich verschiedenste Informationen hinzufügen bzw. weglassen. Man muss dem Nutzer nur die Möglichkeit dazu geben. Nur besteht diese bei Google Maps nicht.
Allerdings gibt es Alternativen, die eine Fülle von Informationen bereit halten, die beispielweise Google Maps nicht liefert. Bei OpenStreetMap finden sich neben Kirchen und Denkmälern auch die Positionen von Briefkästen, Restaurants, Einkaufsmöglichkeiten und Trinkbrunnen in Italien.
Das Problem liegt also nicht im Medium über das eine Karte dargestellt wird, sondern darin, dass Informationen, die durchaus vorhanden sind, nicht in die weit akzeptierten Anwednungen eingebunden sind und viele Nutzer nicht gezielt nach Alternativen suchen.
Mehr zum Thema
Kategorien: Meinungen
Mit Tag(s) versehen: Webmapping
Googles AJAX API bietet nun eine Funktion, mit der man auf Basis der IP der Ort eines Nutzers feststellen kann. Die Funktion kann dazu verwendet werden, um Kartenanwendungen, auf den Ort des Betrachters zu zentrieren.
Ein solches Feature kann durchaus nützlich sein, wenn man Daten mit starkem regionalen bzw. lokalen Bezug darstellen möchte. Ob das immer die beste Wahl ist, bleibt natürlich zu hinterfragen. Oft möchte ich mir beim Betrachten einer interaktiven Karte erst einmal einen Überblick verschaffen, bevor ich mir lokale Details betrachte.
Was die Anwendung allerdings komplett nutzlos erscheinen lässt ist, dass die Lokalisierung eines Nutzers über seine IP offenbar sehr fehlerbehaftet ist. In meinem Fall habe ich den Blogeintrag mit einer Demo aus Jena aufgerufen. Die Karte sagt mit jedoch, dass ich mitten in Erfurt sitze.
Kategorien: Meinungen
Mit Tag(s) versehen: Google Maps
