GIS 5.0 – Smart und vernetzt

Vor Kurzem bin ich auf einen interessanten Artikel von Dave Peters gestossen. Er hat die Evolution von GIS-Software in vier Entwicklungsschritten dargestellt:

  1. In den frühen 80er-Jahren basierten GIS primär auf Skripts. Mit ihnen wurden Daten bereinigt, editiert und visualisiert. Einige Leser dürften sich noch an die Zeit von ARC/INFO erinnern mit seiner Skriptsprache AML (Arc Macro Language).
  2. Erst Ende der 90er Jahre – also fast 20 Jahre später – kamen die ersten objekt-orientierten GIS-Produkte auf den Markt (z.B. ArcGIS Desktop im Jahr 1998). Möglich wurde dieser zweite Entwicklungsschritt mit der effizienteren Programmiertechnik durch eine performantere Hardware.
  3. Im Zug der rasanten Entwicklung des Webs entstanden anschliessend Technologien, um Daten und Services breit verfügbar zu machen. Ein Baustein dieser service-orientierten Architekturen ist beispielsweise die im Jahr 2000 (Version 1.0) verabschiedete Spezifikation des Web Map Services (WMS).
  4. Virtualisierung von Hardware und Zentralisierung von Rechenzentren leiteten den vierten Entwicklungsschritt ein und führten zu cloud-basierten GIS-Portalen. Dabei können Speicherplatz aber auch Rechenleistung den aktuellen Bedürfnissen entsprechend bezogen und wieder abgestellt werden. Das im Jahr 2012 lancierte ArcGIS Online ist ein prominentes Beispiel hierfür.

Jetzt stellt sich natürlich die Frage, was als Nächstes kommt.

abb1
Die vier Entwicklungsschritte der Evolution von GIS-Software.

 Smarte und vernetzte Systeme

Aus der Vergangenheit lernen wir: Neue technologische Möglichkeiten führen zu neuen Anwendungen und beeinflussen in hohem Masse auch die Weiterentwicklung von GIS. Zu den für die Zukunft von GIS relevanten Technologien und Entwicklungen zähle ich

  • die Indoor-Navigation,
  • das Internet der Dinge (Internet of Things, kurz IoT) sowie
  • Echtzeit-Systeme.

Künftige GIS-Anwendungen werden zunehmend smart und vernetzt. Sie erfordern eine neue technische Infrastruktur, welche sich aus verschiedenen Schichten zusammensetzt. Dazu gehören eingebettete Systeme, Netzwerkkommunikation und ein cloud-basiertes System, aber auch Werkzeuge zur Gewährleistung der Datensicherheit, ein Gateway für die Einbindung externer Informationsquellen sowie die Integration der eigenen Unternehmenssysteme (siehe Abbildung unten, abgeändert nach Porter und Heppelmann).

abb2
Die Architektur von smarten, vernetzten GIS-Anwendungen.

Der Geschäftsbereich Informatik von Ernst Basler + Partner (EBP Informatik) hat bereits in mehreren dieser Bereiche Erfahrungen gesammelt (vgl. unsere Referenzprojekte). Auch in unseren Blogposts beschäftigen wir uns immer wieder mit diesen Zukunftsthemen, wie z.B. die Beurteilung von Datenqualität bei Realtime-Sensoren.

Does Web Mercator imply erroneous geospatial positioning?

Web Mercator nowadays is probably the most frequently used map projection. Don’t worry if you have never heard about it though. This new projection is used by Google Maps, Bing Maps by Microsoft, ArcGIS Online by Esri and the OpenLayers community. It became the standard of displaying geographic data on the web.

There are rumours that this standard is bad because it implies tremendous geospatial positioning errors. The Office of Geomatics at the U.S. National Geospatial-Intelligence Agency (NGA) puts the cost of using Web Mercator as follows:

up to 40.000 meters of erroneous geospatial positioning

So, what is wrong with Web Mercator?

Let’s take a step back: A map projection solves the problem of representing the 3D earth on a 2D plane, i.e. on a paper map or on a computer screen. The transformation from 3D to 2D involves distortions in one way or another. Of course, simply superimposing the outlines of Great Britain in two different projections (as the NGA did in the publication Implementation Practice Web Mercator Map Projection) results in shifts, see NGA’s figure below. And yes, the outlines do not match.

Comparison-Mercator-WebMercator

Distortions are what map projections are about! We therefore cannot talk about positioning errors when comparing different map projections such as the siblings Mercator and Web Mercator.

Given the fact that we have to live with distortions on maps we have to choose a map projection that suits a given purpose well. A map projection is therefore more or less appropriate for depicting a particular spatial fact or for accomplishing a specific task in space. Thus, a projection is neither good nor bad. Rather, its suitability has to be judged with the purpose in mind.

 

Alice had no idea what Latitude was, nor Longitude either, but thought they were nice grand words to say.

These are nice grand words indeed! However, other than Lewis Caroll’s Alice in the Wonderland we must have an idea at least what latitude means when talking about map projections. There are many latitudes to choose from:

On the sphere we know the spherical latitude. It is the angle between the normal to the sphere and the equatorial plane. On the ellipsoid with the two semi axis a and b (see figure below) we distinguish the geodetic latitude Φ or φ. This is the angle between the normal to the ellipsoid and the equatorial plane. The geocentric latitude γ is the angle between the radius (from the centre to the point on the ellipsoid) and the equatorial plane. Finally, there is the reduced latitude β that is used when transforming latitudes from sphere to ellipsoid.

Latitudes

When talking about latitude or geographic latitude we generally refer to the geodetic latitude. What the above figure also shows is that the definition of the latitude must be accompanied with the definition of an ellipsoid (e.g., semi-major axis and eccentricity).

On top of knowing the reference ellipsoid we must also know the geodetic datum that defines the position and orientation of the ellipsoid in relation to the geoid. When somebody uses WGS84 coordinates this most probably means

  1. The data is in geographic coordinates: geodetic latitude φ and longitude λ
  2. The coordinates refer to the WGS84 ellipsoid
  3. The ellipsoid is positioned and orientated relative to the geoid according the WGS84 datum

We now know the inputs, geodetic latitude φ and geodetic longitude λ, to our equation. Let’s examine the equation itself, the (Web) Mercator projection. There is a difference in how the vertical coordinate value (northing) is computed:

Northing-Formulas

where:

a = semi-major axis of ellipsoid

e = ellipsoid eccentricity

φ = geodetic latitude a.k.a. geographic latitude

As the formulas show, Web Mercator simplifies the computation of northing considerably. In fact, it uses the equation for the sphere in combination with a sphere radius corresponding to the semi-major axis of the WGS84 ellipsoid. This simplification speeds up the projection computation.

Thus, when you require a projection that covers the entire globe seamlessly, Web Mercator is appropriate when you are interested in fast coordinate transformations. On the other hand, when your map needs to be conformal Mercator is your choice. I think it was a smart idea to simplify Mercator for web mapping purposes into Web Mercator.

Perhaps you noted that we didn’t talk about elevations. That’s another tricky story. Would you believe that Lake Constance has three different mean sea levels? I will post about that another time.

If you found this analysis interesting: The performance of in-browser translation enginges keeps getting better. Thus, consider subscribing to our RSS feed that features all our articles (also the ones in German). If you are only interested in English articles, you may want to subscribe to our custom RSS feed for articles in English. We’d be glad to welcome you in our community!

Aus WebGIS wird GIS: Eigene Daten im Geoportal

Vor knapp 3 Jahren haben wir über das Geoportal map.geo.admin.ch und dessen Programmierschnittstelle berichtet. Seitdem hat sich einiges getan: Die Webkarten wurde komplett überarbeitet und auch die API ist seit einigen Tagen aktualisiert (und die alte API Version wird Mitte Jahr eingestellt!). Die neue Webapplikation bietet neben einer verbesserten Nutzerführung auch auf mobilen Geräten auch eine verbesserte Suche nach Daten und Themen. Ein neue Option ist jedoch etwas versteckt, aber höchst interessant: Drag’n’Drop.

Beispiel einer KMZ Datei auf geo.admin.ch (Steuerertrag Kanton Zürich).
Beispiel einer KMZ Datei auf geo.admin.ch (Steuerertrag Kanton Zürich). Die Datei wurde mit der Webapp send2geoadmin hochgeladen.

„Aus WebGIS wird GIS: Eigene Daten im Geoportal“ weiterlesen

GeoSEO – Findet man Ihre Geodaten mit Google?

Wir betreiben diesen Blog mittlerweile seit drei Jahren. Mehr oder weniger regelmässig veröffentlichen wir hier einige unserer Ideen und Analysen, die ausserhalb unseres eigentlichen Tagesgeschäfts sind. Unter Anderem haben wir im Jahr 2010 „auf die Schnelle“ einen Blogpost über Geländeprofile geschrieben und eine dazu passende statische Webapplikation veröffentlicht. Heute ist unser Traffic auf durchschnittlich 200 bis 400 Pageviews pro Tag angestiegen.

geo-seo

Aber wie kommen die Leute auf geo.ebp.ch? Ganz einfach: 80%-90% entdecken uns über die Internetsuche nach einem „Höhenprofil“ oder „Geländeprofil“. So etwas nennt man wohl zufällige Suchmaschinenoptimierung oder „accidental search engine optimization (SEO)“.

Mit dieser Beobachtung und dem Artikel von Brian Timoney haben wir uns die Frage gestellt: Wieviele Internetnutzende kommen über Google (et al) direkt zu einer Karte der Schweizer Geoportale, die auch ihrem Suchbegriff entspricht? Wenn ich beispielsweise nach „Antennenstandorte in Meilen“ suche (oder nur nach „Antennenstandorte“, da ich gerade in Meilen bin), erhalte ich nicht sofort einen entsprechenden Kartenausschnitt. Erst nach einigen Klicks und weiteren Suchbegriffen bekomme ich die gewünschte Information und Darstellung auf der Karte.

Das Problem ist, dass Google und andere Suchmaschinen die Objekte in einer interaktiven Webkarte nicht indizieren. Aber unser Anfangsbeispiel zeigt, dass Google potenziell sehr viele Besucher vermitteln kann. Daher lautet die Frage: Wie können wir die Auffindbarkeit von Informationen in Geoportalen verbessern?

„GeoSEO – Findet man Ihre Geodaten mit Google?“ weiterlesen

Webkarten kosten Geld – jetzt auch bei Google. Ein Preisvergleich. (Update)

(Updates siehe unten)

Im Frühling dieses Jahres haben  wir über unsere ersten Erfahrungen mit der Swisstopo API für Webkartendienste berichtet . Seitdem hat sich die API weiter entwickelt: Unter anderem sind einige neue Datenebenen hinzugekommen und eine adressgenaue Suche ist jetzt ebenfalls möglich. Auch  ein mobiler Webclient  auf Basis von HTML5 ist jetzt offiziell verfügbar. Damit hat sich für die Schweiz eine durchaus interessante Alternative zu  Google Maps  entwickelt, dem de-facto Standard für Webkarten für Konsumentinnen und Konsumenten.


„Webkarten kosten Geld – jetzt auch bei Google. Ein Preisvergleich. (Update)“ weiterlesen

Swisstopo API für alle: Ein erster Eindruck

Der Kartenwebdienst map.geo.admin.ch des Bundes ist schon seit einiger Zeit online und bietet einen schnellen und technisch hervorragend gemachten Zugang zu räumlichen Informationen des Bundes an. Unter Anderem sind die Landeskarten mit Massstab 1:25’000 und hochauflösende Luftbilder über den Browser abrufbar. Auch eine grosse Anzahl thematischer Layer sind verfügbar. Die zugrundeliegende Serverinfrastruktur basiert u.A. auf Amazons Web Services und ist sicherlich genauso spannend wie die Implementierung des WMTS und die Applikationsschicht auf Basis der ExtJS, GeoExt und OpenLayers Bibliotheken.

Screenshot map.geo.admin.ch

„Swisstopo API für alle: Ein erster Eindruck“ weiterlesen

Die neuen Basisdaten für Google Maps

Screenshot Google Maps vom 11.11.2010

Am 9. November 2010 hat Google bekanntgegeben, dass innerhalb der nächsten 24 Stunden für gewisse Gebiete in Teilen Europas (und Australien, Neuseeland, Südafrika) auf eine neue Datengrundlage umgestellt wird:

These map updates will improve our geocoding and directions, increase the accuracy and coverage of natural features such as forest and water bodies, and add walking paths and bicycling trails.

Gemäss Screenshot stammen die Kartendaten in Zürich von AND (Automotive Navigation Data; Wikipedia), einem unabhängigen (von Navteq/Nokia und TeleAtlas/TomTom) Anbieter digitaler Karteninhalte.

Screenshot Google Maps vom 11.11.2010
Screenshot Google Maps vom 11.11.2010

Für ein Kundenprojekt haben wir im Juni 2010 knapp 4200 Adressen geokodiert. Nun liegt natürlich nichts näher, als die bestehende Geocodierung zu wiederholen und die Resultate zu vergleichen:

Kriterium Juni 2010 November 2010
Anzahl Adressen 4177
davon:
… grundstücksgenau geocodiert 3 / 0.07% 6 / 0.14%
… adressgenau geocodiert 4031 / 96.5% 4057 / 97.13%
… strassengenau geocodiert 68 / 1.63% 38 / 0.91%
… PLZ-genau geocodiert 55 / 1.32% 57 / 1.36%
… ortschaftsgenau geocodiert 15 / 0.36% 14 / 0.34%
… nicht geocodiert 5 / 0.12% 5 / 0.12%

In der Folge habe ich die Lageunterschiede der exakt (adress- oder grundstückgenau) geocodierten Adressen angeschaut. 4013 Adressen waren in beiden Analysen exakt geocodiert worden. Wie die folgende Tabelle zeigt, beträgt der Mittelwert der Abweichungen etwas über 20 Meter. Die Verteilung der Abweichungen ist ziemlich schief; sehr viele Adressen hatten keine Abweichung, nur 284 Adressen hatten positive Abweichungen (deshalb Median-Abweichung von 0 Metern).

In einem zweiten Schritt habe ich nur die Abweichungen > 0 m angeschaut. Der Median der Abweichungen in dieser Gruppe beträgt etwas über 35 Meter.

Abweichungen der adress- oder grundstücksgenau geocodierten Adressen
Mittelwert der Abweichungen zwischen der ersten und der zweiten Geocodierung 22.7 m
Median der Abweichungen 0 m
Median der Abweichungen > 0 m 36.7 m

Die Abweichungen zwischen den beiden Geocodierungen scheinen mit solch einem Median nicht sehr gross. Je nach Anwendung kann eine solche Abweichung aber natürlich trotzdem wichtig sein.

Interessanterweise zeigt die Analyse, dass die Geocodierung von 21 Adressen schlechter geworden ist (4013 Adressen sind in beiden Geocodierungen exakt, 4034 in der ersten). Allerdings ist dies nicht die ganze Geschichte. Tatsächlich ist die Geocodierungsqualität von Google anhand der von Google angegebenen Genauigkeit seit Sommer 2010 über alles gesehen ein bisschen besser geworden. Wie die erste Tabelle dokumentiert, ist die Anzahl exakt geocodierter Adressen tendentiell gestiegen und jene der schlecht geocodierten Adressen gesunken. Dies sehe ich denn auch als die hauptsächliche Verbesserung der Google-Geocodierung seit Sommer 2010. Ob diese Qualitätsverbesserung aber auch zu einer wirklich exakteren Positionierung der Adressen führt, kann ohne ground truth natürlich nicht beurteilt werden.

Luftbilder oder Satellitenbilder?

Jeder, der mit Google Maps gearbeitet hat, kennt den Knopf  mit der Aufschrift „Satellit“, mit dem sich eine fotografische Vogelperspektive der Erde auf den Bildschirm zaubern lässt. Dabei schaut der „Vogel“ in der Regel direkt nach unten – die sogenannte Nadirperspektive (Schrägbilder haben wir in einem unserer früheren Artikel erwähnt).

Aber auf welcher Höhe fliegt der  „Vogel“? Sind es wirklich Satelliten, die das Bildmaterial liefern (Satellitenbild, Fachrichtung Fernerkundung), oder wurde das Gelände (auch) mit Hilfe von Flugzeugen beflogen und aufgenommen (Orthofoto, Fachrichtung Photogrammetrie)?

Wenn man dem Google Satellit-Knopf glauben dürfte, ist die Frage eigentlich beantwortet. Bei genauerem Hinsehen stellt man jedoch fest, dass in einigen Gegenden die Auflösung wesentlich besser ist als 0.5 m, die aktuell maximal zu erreichende Bodenauflösung eines zivilen Satelliten (GeoEye-1 oder WorldView-2), zum Beispiel:

In der Legende sieht man, dass neben GeoEye auch photogrammetrische Firmen wie AeroWest oder Aerodata als Datenquellen erwähnt sind. Ob diese Liste hinreichend ist und welche Datenquelle effektiv genutzt wurde, ist leider nicht ersichtlich.

Für die Schweiz hat Google die Firma BSF Swissphoto beauftragt, neue Daten zu erheben. Die flugzeuggestützte Erfassung startete im Jahr 2009 und wird dieses Jahr abgeschlossen werden. Als Kamera setzt BSF Swissphoto eine Vexcel UltraCamXp ein – pikantes Detail: von Microsoft. Dieser Sensor ermöglicht Bildaufnahme von 17’310 x 11’310 Pixel (196 Megapixel), und zwar in vier Farbkanälen Rot, Grün, Blau und Infrarot. Damit sind neben einem Echtfarbenbild auch Falschfarben-Infrarot-Darstellungen möglich.

Bereits Ende 2010 dürfte unter den Google Maps-Satellit-Karten der Schweiz der Hinweis stehen: Grafiken (c) 2010 …, …, BSF Swissphoto. Wir sind gespannt.

Konkurrenz belebt das Geschäft: Google Maps und Bing Maps

Gestern gab Google bekannt, dass in bestimmten Regionen Schrägaufnahmen in den Luftbildern enthalten.  Im verlinkten Beispiel werden die Schrägaufnahmen ab einem bestimmten Zoomfaktor automatisch angezeigt. Die Schrägaufnahmen sind also direkt mit den Satelliten und anderen Orthofotos verlinkt. Zusätzlich kann man noch die Anzeige rotieren lassen und so ein Gebäude von (fast) allen Seiten anschauen. Leider funktioniert das Ganze nur in zwei US-amerikanischen Städten, wir in der Schweiz müssen uns wohl noch etwas gedulden.

Beispiel für Schrägaufnahme in Google Maps
Beispiel für Schrägaufnahme in Google Maps

Microsoft bietet diese Funktionalität  schon seit längerem in Bing Maps an, dort nennt es sich „Vogelperspektive“ („Birdseye View“). Daten stammen von der Firma Pictometry, woher Google seine Schrägaufnahmen bezieht, ist mir nicht bekannt. Vorteil von Microsofts Vogelperspektive ist, dass sie weltweit verfügbar sind, zum Beispiel auch an unserem Standort:

Vogelperspektive EBP in Bing Maps
Vogelperspektive EBP in Bing Maps

Google hat damit also bezüglich dem Produktangebot mit Microsoft gleichgezogen. Andererseits hat Microsoft die nicht nur in der Schweiz heftig diskutierten Streetviews in ihre Applikation eingeführt. Dazu muss man in der Betaversion das Browserplugin „Silverlight“ verwenden.

Schön, dass durch die Konkurrenz die Produkte verbessert werden. Nach den technologischen Änderungen darf man nun gespannt sein, wer das Wettrennen um die beste weltweite Abedckung gewinnt. Bei Streetview hat Google die Nase weit vorne, bei den Schrägaufnahmen Microsoft. Nicht nur meine Vermutung ist, dass Google durch mögliche Werbeeinnahmen mehr Ressourcen einsetzt, um den Wettlauf zu gewinnen.

Kartografie bei Google Maps: Meistens gut, manchmal nicht so ganz.

Preisfrage: Was springt bei dieser Kartendarstellung als erstes ins Auge?
Preisfrage: Was springt bei dieser Kartendarstellung als Erstes ins Auge?

Keine Frage, Google Maps hat in den letzten Jahren den GIS Markt verändert, geöffnet, erweitert. Und Google Maps ist wohl das gebräuchliste WebGIS – vielleicht auch, weil es so einfach zu bedienen ist. Wir benutzen die API und das Kartenmaterial von Google erfolgreich in einigen Projekten. Ein paar Nachteile muss man aber in Kauf nehmen.

Die Geländekarte von Google ist grundsätzlich eine gute Basiskarte für die Einbindung eigener Datenlayer. Dass Strassennummern in der aktuellen Karte durch auffälliges Rot und Blau gekennzeichnet sind, finde ich jedoch nicht optimal. Dafür dass Strassen eine nebensächliche Information in einer Geländkarte sind, werden sie durch den Anwender zu stark wargenommen. Zudem beissen sich Rot und Blau möglicherweise mit den Farben eigener Datenlayer.

Vielleicht wird ein Layer von OpenCycleMap (von OpenStreetMap) eine frei verfügbare Alternative?

(Update 27. Oktober 2010: Es geht doch mit Google Maps!)