Vom Entwickler zum Architekten: Teil 1

Einem erfahrenen Softwareentwickler kann es passieren, dass er im Lauf der Zeit immer mehr in die Arbeit eines Softwarearchitekten rutscht und den Übergang vom Schreiben von Code zum Design von Systemen vollzieht – zuerst für Offerten, bald aber auch in der Umsetzungsphase. So ist es auch mir ergangen. Trotz eines Informatikstudiums im Rücken fühlte ich mich in der Vergangenheit bei kniffligen Architekturaufgaben aber manchmal etwas unsicher: Mache ich das richtig? Gibt es vielleicht einen besseren Weg Architekturfragen anzupacken als den von mir eingeschlagenen? Um meine Methodik der Erstellung von Softwarearchitekturen auf eine solidere Basis zu stellen, habe ich beschlossen, mich im Rahmen eines Kurses intensiver damit auseinanderzusetzen. Meine Erfahrungen auf diesem Weg möchte ich in drei Blogposts schildern – willkommen bei Teil 1!

Folgende Fragen haben mich in den letzten Jahren als Softwarearchitekt beschäftigt:

  • Was genau umfasst eine Softwarearchitektur?
  • Was genau umfasst die Arbeit eines Softwarearchitekten?
  • Gibt es eine Methodik, der ich folgen kann?
  • Wie kann ich die Softwarearchitektur den diversen Stakeholdern im Projekt gut kommunizieren?
  • Wie kann die Güte einer Architektur gemessen werden?

Der oben angesprochene Kurs, der in meiner Zertifizierung als Softwarearchitekt ISAQB Foundation Level gipfelte, hat mir dabei geholfen, diese Fragen zu klären. Und auch Fragen, die ich mir bisher nicht gestellt hatte (aber besser hätte sollen). Im Vorfeld des Kurses hatte ich mich intensiv mit dem Buch «Effektive Softwarearchitekturen – Ein praktischer Leitfaden» von Dr. Gernot Starke auseinandergesetzt. Da mein Informatikstudium bereits ein paar Jahre zurückliegt, kam das Studium dieses Buches gelegen, um festgefahrene Mechanismen und Meinungen meinerseits zu hinterfragen und aufzubrechen.

Architektensicht: Der Blick auf das grosse Ganze

Die Gretchenfrage

Beginnen wir mit der Gretchenfrage: Was ist Softwarearchitektur?

In erster Linie unterstützt die Architektur den herausfordernden Übergang von der Problemanalyse zur konkreten technischen Lösung. Schliesslich wird ein zu implementierendes System basierend auf seinen Komponenten und deren Beziehungen untereinander beschrieben. Wichtig ist, dass Architektur weit mehr ist als das Skizzieren einer technischen Lösung! Eine gute Architektur ermöglicht:

  • Herr werden über Einflüsse: Neben den funktionalen Anforderungen wird die Architektur unter anderem auch von Budget, Qualitätsanforderungen (auch «nicht-funktionale Anforderungen» genannt), organisatorischen Randbedingungen, rechtlichen Vorgaben oder gar von Politik beeinflusst. Softwarearchitektur kann diese Einflüsse aufzeigen und behandeln.
  • Herr werden über Komplexität: Architekturen dienen dazu, komplexe Anforderungen explizit zu machen und sie in umsetzbare Strukturen zu übersetzen.
  • Effektive Kommunikation: Architektur kann technische Systeme aus verschiedenen Blickwinkeln («Sichten») zeigen und hilft so allen Beteiligten, verständlich und wirksam miteinander über ein System zu sprechen. Diesem Thema widme ich Teil 2 dieser Blogserie.
  • Iterative Verbesserungen: Eine Softwarearchitektur entsteht iterativ und somit begleitend zur eigentlichen Entwicklung des Systems. Entscheidungen, die zu Beginn des Projektes gefällt wurden, sollen während der Umsetzung kritisch hinterfragt und gegebenenfalls angepasst werden.
  • Ziele im Blick behalten: Die Architektur eines Systems soll langfristige Ziele abbilden und mögliche Zielkonflikte mit (eher kurzfristigen) Projektzielen auflösen.
  • Unterstützung des Lebenszyklus: Richtig angegangen unterstützt Architektur den gesamten Lebenslaufs eines Systems: Von der Anforderungsanalyse über Entwicklung bis zum Betrieb von Systemen.

Nun da wir eine Idee davon bekommen haben, was Softwarearchitektur ist: Was ist denn die Rolle des Architekten? Softwarearchitekt zu sein bedeutet viel mehr, als nur Anforderungen des Kunden in eine geeignete technische Struktur abzubilden und dann den Entwicklern die Umsetzung zu überlassen.

Folgende Grafik zeigt die wesentlichen Aufgaben des Softwarearchitekten.

Stacks Image 114

(Quelle: Arc42)

Von der Wichtigkeit des breiten technischen Portfolios

Der Architekt klärt die Anforderungen und Randbedingungen und giesst diese in ein System, indem er Strukturen (Komponenten und ihre Beziehungen) sowie querschnittliche Konzepte entwirft und festhält. Er kommuniziert die Architektur gegenüber den relevanten Stakeholdern – zum Beispiel dem Product Owner, dem Entwicklungsteam, der Projektleiterin, dem Testteam, dem Betreiber etc.) – und begleitet die Umsetzung. Die Pfeile in der obigen Grafik signalisieren, dass es sich um einen agilen Prozess handelt. Ein Softwarearchitekt ist also nicht «nur» ein «Techie», er ist auch Vermittler zwischen den Stakeholdern. Im Endeffekt verantwortet er das System, das umgesetzt wird. Dieser Umstand setzt mich etwas unter Druck: Kenne ich

genügend gut, um stets zur richtigen Entscheidung zu gelangen? Nützlich ist hier der Aufbau eines eigenen breiten technischen Portfolios, das man im Sinn des persönlichen Wissensmanagements stetig erweitert (was bei EBP angesichts der Fülle unserer Projekte gut gelingt). Meines dokumentiere ich vorzu in Form eines Mindmaps.

Das ewige Balance-Spiel: Ausgleich von Zielkonflikten

Darüber hinaus stellt sich immer die Frage, ob man mit seinen Architekturentscheidungen allen Anforderungen und Rahmenbedingungen gerecht wird. Folgendes Zitat von Philippe Kruchten bringt das bisweilen herrschende Gefühl etwas düster auf den Punkt:

«The life of a software architect is a long and rapid succession of suboptimal design decisions taken partly in the dark».

Offenbar bin ich nicht alleine mit meinen Sorgen! Zeit, diese zu teilen: Softwarearchitektur darf nicht im stillen Kämmerlein entstehen. Wenn Sie mit Architekturfragen betraut sind: Beziehen Sie die wesentlichen Stakeholder früh in den Prozess mit ein – etwa die (Senior-)Softwareentwickler und -entwicklerinnen, an die Sie technische Abklärungen delegieren. Holen Sie rechtzeitig Feedback ein von den Security-Profis und den Betriebsspezialisten. Diese und ähnliche Schritte steigern meiner Erfahrung nach die Qualität von Entscheidungen massgeblich. Und sie sorgen gleichzeitig dafür, dass das Wissen im Projekt besser verteilt und somit ein gängiges Projektrisiko eliminiert ist.

Next up: In Teil 2 meiner Blogserie möchte ich gezielt auf ein weiteres Kästchen im obigen Bild eingehen, nämlich auf das Kommunizieren der Architektur.

A new map in town: MapKit JS by Apple

Back in 2011, #TeamEBP has written about the usage of geo.admin.ch and compared it to other map services like Google. A year later, Apple joined the party of map providers and introduced Apple Maps to the world, with one caveat: It was only available on Apple devices. With Apple’s developer conference last week, this has changed: Apple introduced a new Javascript library called MapKit JS from Apple – this means that you can now embed a webmap by Apple on any of your websites. Currently the API is in beta, but the documentation is already available, including sample code. If you need even more information: check the WWDC session video, the demos begin at 26:00, 43:45, the slides are at available as PDF.

Unfortunately the basemap quality is not that good for Switzerland (compared to California, at least), so this blog post is not suggesting you to migrate and use it in production. However, you can get inspired, the codebase is a sum of rich and beautiful APIs with many concepts borrowed from the MapKit native which exists in iOS since its first release, more than 10 years ago.

One important thing to note is pricing: As we’ve written in 2011, no webmap comes for free, if used heavily. Apple’s expected pricing strategy according to the presentation is interesting: you can use 250’000 map initializations and up to 25’000 service requests (geocoding, search with autocomplete, directions) for free, per day (sic!). This is about 10 times more than what Google charges you with their recent price change (One caveat: it’s hard to compare pricing for mapping APIs directly, so take this number with a grain of salt). Note however, that you need an API key in order to use MapKit JS, for which an Apple Developer account is necessary (which again costs you CHF 109 per year).

I’ve also made a simple CodePen Demo with a WMTS layer from ArcGIS Online and walking directions from Apple’s routing service. The WMTS layer shows a quality of service map for public transportation stops, computed with Walkalytics.

See the Pen EBP MapKitJS Demo by Stephan Heuel (@ping13) on CodePen.

Here is a direct link to the JS code of the demo.

Are you interested in using MapKit JS standalone or in combination with other mapping services? Get in touch with Stephan Heuel or myself, we would love to talk with you. 

GeoPython Konferenz 2018

Bereits zum dritten Mal öffnete die Fachhochschule Nordwestschweiz (FHNW) ihre Tore zur GeoPython-Konferenz. Während dreier Tage trafen sich vom 7. bis 9. Mai Geo-Interessierte aus aller Welt in Muttenz, um über die neuesten Trends und Packages rund um Python zu diskutieren. Da wir bei EBP Python oft auch für Datenanalysen und die Arbeit mit Geodaten einsetzten, war ich für EBP dabei und möchte Ihnen einen Überblick über die Veranstaltung geben.

Räumliche Analysen mit GeoPandas

Martin Christen eröffnete die Konferenz ganz unkonventionell (und sehr sympathisch) mit einer rein analogen Ansprache ohne PowerPoint, Beamer und Co. sowie dem Versprechen, dass die GeoPython 2019 im brandneuen FHNW–Standort stattfinden werde. Pünktlich zum Beginn der ersten Workshops  war auf technischer Seite alles wieder bereit und schon stand eine schwierige Entscheidung an: Soll es der Workshop zur Datenanalyse mit GeoPandas werden oder jener zur Erstellung von QGIS-Makros mit PyQGIS?

Ich habe mich für GeoPandas entschieden und diese Wahl keineswegs bereut: Joris Van den Bossche führte nachvollziehbar und verständlich mittels Jupyter Notebooks durch die Funktionalitäten von Shapely, Pandas und GeoPandas. Insbesondere Coderinnen und Coder, die bereits mit der Programmiersprache R gearbeitet haben, werden das hier verwendete GeoDataFrame-Konstrukt wiedererkennen und schätzen. Dieses erlaubt es beispielsweise, räumliche Operationen nicht nur auf einzelne Objekte, sondern gleich auf alle Elemente einer Matrix anzuwenden. Der Workshop behandelte neben den möglichen räumlichen Operationen auch die Visualisierung der Resultate und gab einen guten Überblick über die Möglichkeiten von GeoPandas.

Der GeoPandas Workshop war gespickt mit Übungen zum selbst Programmieren. Die Verzahnung von Theorie- und Code-Blöcken gehört definitiv zu den Hauptvorteilen von Jupyter-Notebooks. Quelle: GeoPython 2018

Nachbarschaftsmatrizen als räumliche Alternative

GeoPandas begegnete den Teilnehmenden dann auch wieder beim Data Science Workshop am Nachmittag. Im Fokus stand dabei allerdings ein anderes Thema, nämlich PySAL. Dieses Package stellt diverse Methoden zur statistischen Auswertung und räumlichen Analyse zur Verfügung. Für Letzteres nutzt PySAL, anders als GeoPandas, Nachbarschaftsmatrizen. Über solche Matrizen wird festgehalten, welche Art von räumlicher Beziehung besteht und wie stark sie ausgeprägt ist.

Beispielsweise lässt sich ausgehend von einem Punktdatensatz die Nachbarschaft mittels Berechnung der Thiessen-Polygone bestimmen, wobei die Distanz der Punkte untereinander auch gleich die Gewichtungsmatrix ergibt. Je nach gewähltem Kriterium resultieren dabei andere Nachbarschaften. Das Rook-Kriterium beispielsweise sieht vor, dass zwei Polygone sich mindestens eine Kante  teilen müssen, um als Nachbarn zu gelten (vgl. Rook’s Case in Rasteranalysen). Auf den Nachbarschaftsmatrizen lassen sich räumliche Analysen wie beispielsweise eine Kernel Density Estimation (KDE) sehr schnell und ressourcenschonend berechnen.

Um die Nachbarschaftsmatrix eines Punkt-Datensatzes zu erstellen, werden Thiessen Polygone gebildet (links). Rechts ist die Nachbarschaftsmatrix grafisch dargestellt. Quelle: Levi John Wolf und Serge Rey auf github.

Big Data leicht gemacht

Ein weiterer Schwerpunkt der GeoPython war Machine Learning. Anhand verschiedener Projekte wurde demonstriert, wozu neuronale Netze bereits fähig sind. Beispielsweise um Verspätungen im öffentlichen Verkehr vorherzusagen. Anhand der Echtzeitpositionen der Busse, dem Soll-Fahrplan und weiteren Variablen wie Wetter und Ferienkalender wurde ein Modell trainiert, das als Entscheidungsgrundlage für das Busunternehmen dienen soll. Damit sollen unter anderem die Kundeninformation verbessert oder Extrabusse bei Bedarf möglichst ökonomisch eingesetzt werden.

Ein anderes Projekt verwendete Machine Learning im klassischen Anwendungsfall der Bilderkennung, um zum Klettern geeignete Felswände in unbekannten Gebieten zu entdecken. Wie in den anderen Machine Learning Projekten wurde auch hier eine Kombination aus Pandas, TensorFlow und Keras eingesetzt. Das manuell erstellte Trainingsdatenset wurde in TensorFlow geladen, um den Klassifikator zu trainieren, der anschliessend Luftbildern einen «Klettergebiet» Score zugewiesen hat. Auch wenn der Referent noch keine Gelegenheit fand, sämtliche potenziellen Klettergebiete selbst zu «verifizieren», waren die bisherigen Ergebnisse bereits vielversprechend.

Einen sehr anschaulichen Beitrag zum Themenblock bildete der Vortrag von Google, bei dem die verschiedenen hauseigenen Machine Learning APIs vorgestellt wurden. Anstatt eigene Modelle zu trainieren, kann durch die APIs auf fixfertig trainierte und spezialisierte Modelle zurückgegriffen werden. Diese umfassen beispielsweise Textanalysen, bei denen sowohl der Inhalt als auch die Stimmungslage ausgewertet werden. Auch Google Translator basiert seit einiger Zeit auf einem neuronalen Netzwerk, was gegenüber dem früheren statistischen Modell eine deutliche Verbesserung beim Übersetzen von ganzen Sätzen gebracht habe. Ein besonderes Augenmerk legte der Referent auf die Vision API zur Bilderkennung. So demonstrierte er sehr eindrücklich dessen Fähigkeiten, indem er Fotos vom Eiffelturm in Paris und von dessen Replikat in Las Vegas auswerten liess. Dass der Eiffelturm als solches erkennt wurde, war zugegebenermassen nicht allzu überraschend. Dass aber das Replikat zuverlässig in Las Vegas verortet wurde, obwohl keine anderen baulichen Erkennungsmerkmale im Hintergrund zu sehen sind, war hingegen erstaunlich.

Dies ist nicht der Eiffeltum in Paris, sondern dessen Nachbildung beim Paris Hotel and Casino in Las Vegas. Kein Problem für Google Vision. Quelle: Laurent Picard auf Speaker Deck.

Wissensdurstige aus aller Welt

Dies war mein erster Besuch an der GeoPython. Was mich rückblickend am Meisten erstaunt hat, war, wie international diese Konferenz ist. Nicht nur die Vortragenden kamen aus aller Welt, auch das Publikum war geografisch bunt gemischt. Wie ich in persönlichen Gesprächen mit auswärtigen Teilnehmenden erfahren habe, kommt dies nicht von ungefähr: Im Vergleich zu anderen Python-Veranstaltungen schätzen sie vor allem die sachbezogenen Präsentationen und den Austausch mit gleichgesinnten Fachleuten (ein Faktor, der ja auch das GeoBeer attraktiv macht). So verwundert es dann auch nicht, dass die GeoPython sich ein solches Renommee erarbeitet hat – ziemlich beachtlich für eine erst dreijährige Veranstaltung!

Die GeoPython 2018 endete nach vielen lehrreichen Präsentationen und interessanten Gesprächen. Ich freue mich jedenfalls schon auf die GeoPython 2019.

Pedestrian Reachability Analysis for Hyperlocal Marketing

Since 2013, EBP has been developing and refining Walkalytics, an approach to data analytics for business-relevant questions regarding pedestrian mobility. At the heart of the approach lie isochrones, which are calculated for every square meter of an area-of-interest. In the early stages, we successfully applied Walkalytics mainly in urban and transportation planning. In this blog post, however, I want to demonstrate how Walkalytics can help you in geomarketing on very small scales.

Example 1: Narrow the audience of a direct mailing campaign

As a first example, let’s assume you are big transportation agency with a large customer database that also features a postal address for each of your customers. Let’s further assume you want to send some customers a special offer by mail – but only to the segment of customers who are most likely to accept your offer. In other words, you want to narrow your target audience, if only to save printing and postage costs. A sensible criterion to optimize your campaign’s target audience could be the time that customers take to reach the next transit stop (or any other customer contact point of your liking) on foot.

With Walkalytics, we have the solution to your task: We’ve taken all Swiss addresses from the federal register of buildings and calculated the walking time from each address point to the closest transit stop. You can use this massive dataset to narrow the segment of customers that will be targeted in your campaign. You don’t even have to ask your in-house geodata expert to help you with your filtering: everything is done directly in your customer database based on our augmentation of your CRM data!

General Post Office mail sorting room, Wellington (source Archive New Zealand)

Example 2: Find the optimal location for your customer contact points

Let’s assume you are a manager in a retail company which wants to find the optimal locations of new service points. As you have a business with lots of walk-in customers (i.e. pedestrians), this means you want to find locations that serve many non- or under-served people within a sensible walking distance or time – say within 5 minutes walking time.

For addressing this need, we took advantage of another government data set: The population and household statistics (STATPOP) and the business demography statistics (STATENT) have a number of indicators that are measured in 100×100 meter units all over Switzerland. For each of the effectively 360,000 units, we calculated a walking isochrone and aggregated relevant indicators such as the reachable residential population or reachable number of, e.g., third sector employees. After completion of our analysis, we know for each 100×100 meter square in Switzerland how many people can reach this location within 5, 10 or 15 minutes of walking. Since your business relies on walk-in customers, this informs your choice of where to open your next service point(s).

Workforce reachable within 5 minutes of walking, in Geneva. Red=high number of people reached, blue=low number.
Residential population reachable within 5 minutes of walking, in Geneva (red=high, blue=low).

Did these examples whet your appetite for geo-augmenting your customer and site data? Are you, for example, interested in filtering your customer database according to the reachibility of your service points? Do you want to optimize locations based on socio-economic statistics? Let’s have a talk, e.g. during GEOSummit in Bern or online using e-mail or Twitter!

Daten austauschen – aber wie?

In welchem Format sollen IT-Systeme Daten austauschen? Modellbasiert mit XML? Oder gibt es auch Gründe, einfache und modellbefreite Formate wie CSV zu verwenden?

Das EBP-Sackmesser: Auch unter neuem Firmennamen das passende Werkzeug für jede (Daten-)Aufgabe.

Wir leben im einem Zeitalter vernetzter IT-Systeme: Applikationen ohne Datenaustausch-Schnittstellen zu anderen Systemen sind kaum noch zu finden. Wie aber tauschen Systeme diese Daten aus? Dazu hatte ich letztens eine interessante Diskussion mit meinem Kollegen Stephan Heuel. Die Erkenntnis daraus: Die Vor- und Nachteile verschiedener Formate ändern mit dem Anwendungszweck – genau wie bei einem Taschenmesser braucht man das passende Werkzeug für eine Aufgabe.

XML und Co. – modellbasiert und umfassend

In den Projekten, an denen ich aktuell arbeite, implementieren wir die meisten Schnittstellen mit XML (oder INTERLIS, aber das ist ja auch XML). XML wird meist benutzt,  wenn ein ausgearbeitetes Datenmodell vorliegt. Die Modelldefinition kann in einem standardisierten Format beschrieben werden und es gibt Werkzeuge, mit denen man Dateien validieren kann. Alle Formate unterstützen die Umsetzung von komplexen Datenmodellen.

Aus meiner Sicht bieten diese Formate verschiedene Vorteile:

  • Die Modellbeschreibung dient als Vertrag für den Datenaustausch. Damit ist für alle beteiligten Systeme klar festgelegt, wie sie die Daten liefern bzw. empfangen müssen.
  • Wenn mein System Daten erhält, kann ich diese mit Standardwerkzeugen einfach validieren, ohne dass ich dafür eigene Prüfmethoden oder -werkzeuge entwickeln muss.
  • Wenn das Datenmodell für den Austausch identisch mit dem Datenmodell meiner Applikation ist, braucht es keine Modelltransformation beim Import oder Export von Daten. Ich muss zugeben, dass das in einigen Fällen eine egoistische Sichtweise ist, weil der Aufwand bei anderen beteiligten Systemen entsprechend höher sein kann. Gerade im Fall von INTERLIS (da wird es ja schnell aufwändig…) ist es aber praktisch, wenn das Transfermodell und die Quell-/Zielmodelle keine grossen Unterschiede haben (die minimalen Geodatenmodelle bilden dafür eine gute Basis).

Aus diesen Gründen schien es mir klar, dass XML in vielen Anwendungsfällen gegenüber Formaten wie CSV die Nase vorn hat. Man könnte statt XML auch JSON als „fett-freie“ Variante von XML benutzen, da man mit JSON auch Modelle und Strukturen abbilden kann.

CSV und Co. – einfach und zugänglich

Ein modellbasierter Datenaustausch über XML ist in der Theorie immer richtig und in der Praxis insbesondere dann, wenn die Beteiligten sich auf das gleiche Daten bzw. Objektmodell geeinigt haben. Leider ist es so, dass in der Praxis nicht von vornherein klar ist, wer die Empfänger von Daten sind und diese nicht unbedingt das darunterliegende Objektmodell kennen – oder gar nicht daran interessiert sind.

  • Aus der Erfahrung sind fachgetriebene Modellbeschreibungen sehr komplex, da jeder Fachexperte, jede Fachexpertin im Zweifelsfall eine Klasse, Attribut oder Relation mehr modelliert statt weniger. Auch minimale Geodatenmodelle sind davor nicht unbedingt geschützt. Dies erschwert die Zugänglichkeit der Daten für Dritt-Entwicklerinnen und -Entwickler teilweise erheblich.
  • Die Werkzeuge für den Datenaustausch müssen zugänglich und umfassend unterstützt werden. Dabei haben natürlich generelle, international weit verbreitete Formate wie CSV einen Vorteil.
  • Als (fachfremder) Empfänger und Nutzer von Daten gehe ich davon aus, dass die gelieferten Daten fachlich korrekt sind – wieso sollte ich die also nochmals prüfen? Oder, wenn ich sie prüfe, dann möchte ich sie für meinen speziellen Anwendungsfall prüfen, die der Produzent der Daten aber nicht unbedingt kennt.

Daher möchte ich als Nutzer die Daten in einem möglichst einfachen Format lesen, das von jeder Software oder API unterstützt wird. Ein für mich gutes Beispiel für ein sehr zugängliches Datenangebot findet man im Bereich der Fahrplandaten: Das Format General Transit Feed Specification (GTFS) ist eine Sammlung von CSV-Dateien und wird weltweit von Transportunternehmen zur Publikation ihrer Daten benutzt, auch wenn sie intern andere Modelle und Formate benutzen. Für die Schweiz gibt es den ÖV-Fahrplan übrigens unter https://opentransportdata.swiss/de/dataset/timetable-2018-gtfs. Die Daten sind einfach strukturiert und simpel zu importieren. Zwar kann man allenfalls manche Spezialfälle nicht einfach abbilden (beispielsweise eine „Aufteilung der Zugkomposition an einer Haltestelle“), kann aber dafür einen niederschwelligen Zugang zu einem gesellschaftlich wichtigen Datensatz anbieten bzw. nutzen.

Das richtige Werkzeug

Was ist also richtig? In einem konkreten Fall ermittelt man für ein System die Anforderungen und entwickelt anschliessend eine passende Lösung. Dabei wird man die oben aufgeführten Vor- und Nachteile berücksichtigen.

Es gibt aber noch einen weiteren wesentlichen Aspekt: Was ist der Zweck des Datenaustauschs? Beim Anwendungsfall von Stephan geht es darum, Daten öffentlich verfügbar zu machen (beispielsweise als Teil einer Open Data-Strategie). Der Herausgeber stellt die Datenqualität sicher und möchte, dass die Daten einfach und breit einsetzbar sind: Es macht wenig Sinn, allen Nutzerinnen und Nutzern für ihr System ein komplexes Datenmodell aufzuzwingen.

Der Anwendungsfall bei den Systemen, welche JSON oder XML verwenden, ist normalerweise ein anderer: Hier empfängt ein System Daten von anderen Systemen. Um die Datenqualität im Zielsystem sicherzustellen, ist eine Prüfung zwingend. Die oben erwähnten Vorteile des modellbasierten Austauschs zeigen hier ihren Nutzen.

Was denken Sie zur Thematik? Gibt es noch weitere Punkte zu berücksichtigen? Wir freuen uns über einen Austausch, zum Beispiel am 6. oder 7. Juni beim GEOSummit in Bern. Ralph Straumann und Stephan Heuel werden EBP am Stand von Esri repräsentieren und freuen sich auf ein Gespräch. Oder sonst über Social Media oder am nächsten GeoBeer.

 

 

Bibliophil in unserer digitalen Welt

Lesen Sie noch Bücher? Interessiert Sie, in welcher Schrift ein Text gesetzt ist? Dann haben Sie bestimmt auch schon mit Bedacht über die Seiten Ihrer Lieblingsbücher gestrichen und sich am glatten, weissen und bisweilen farbigen Papier erfreut. Und da Sie diesen Blogbeitrag lesen, interessieren Sie sich für Themen mit Geo-Bezug. Ich vermute also, Sie sind empfänglich für meinen Buchtipp.

Kürzlich entdeckte ich den Atlas der abgelegenen Inseln von Judith Schalansky. Er wurde 2009 veröffentlicht und erhielt Preise für Buchkunst und Design.

Steckbriefe kleinster Inseln

Im Atlas ist fünfzig kleinsten Inseln je eine Doppelseite gewidmet: Auf der rechten Buchseite ist jeweils die rahmenlose Karte der Insel. Die schlichte Darstellung zeigt die Insel mit Reliefschummerung und – wenn es ein solches gibt – Gewässernetz, angereichert mit das innere Auge inspirierenden Namen und manchmal nüchternen Höhenkoten.

In Orange, der komplementären Farbe zum Meeresblaugrau, sind Strassen und Orte der besiedelten Inseln abgebildet. Der Massstab ist für alle Karten derselbe: 1:125’000. So sprengen einige Inseln fast die ihnen zugedachte Seite, andere präsentieren sich in Seitenmitte wie Perlen auf einem leeren, unendlich weiten Meereshintergrund.

Für alle Inseln gleich ist auch die Übersicht auf der linken Buchseite: Eine Azimuthalprojektion mit der Insel auf dem Pol, der Entfernungsbalken zu den jeweils nächsten markanten Orten, Name und besitzbeanspruchende Nation, geografische Koordinaten, Fläche und Anzahl Einwohnerinnen und Einwohner. Auf einer Zeitachse – auch für alle Inseln die gleiche Skala – sind Datum der Entdeckung und weitere Ereignisse aufgetragen.

Am Schluss des Atlas findet sich ein Glossar und ein Index – wie man es sich von einem Atlas eben gewohnt ist! Der Atlas ist aber nicht nur ein Nachschlagewerk, sondern ein Buch zum Lesen. Judith Schalansky schreibt brillant. Die kurzen Texte zu den Inseln enthalten poetische Perlen und sind ein Genuss auf der Entdeckungsreise zu diesen abgelegenen Orten.

Fingerreisen (Cursorreisen?)

Mit dem Satz

Ich bin mit dem Atlas gross geworden.

leitet Judith Schalansky das Vorwort ein. Sie hatte in ihrer Jugend keine Möglichkeit, ins Ausland zu reisen. Der Untertitel des Buches lautet denn auch: Fünfzig Inseln auf denen ich nie war und niemals sein werde. Ich selbst werde diese Inseln auf jeden Fall bereisen, zumindest auf Google Maps. Dieses schöne Buch, dieser poetische Atlas lädt mich geradezu dazu ein!

 

Weitere Informationen

Judith Schalansky
© S. Schleyer, Suhrkamp Verlag

Atlas der abgelegenen Inseln. Fünfzig Inseln, auf denen ich nie war und niemals sein werde.
Mare, Hamburg 2009
ISBN 978-3-86648-117-6
Buch- und Inselbeschreibung auf Wikipedia
Rezension auf Tobis Blog Lesestunden
Judith Schalansky auf Literaturport

 

SmartSuisse 2018

Am 11. und 12. April 2018 fand in Basel zum zweiten Mal die SmartSuisse-Konferenz statt. Ich habe zusammen mit meiner Kollegin Fabienne Perret (Geschäftsbereich Verkehr) und meinen Kollegen Kaspar Fischer (Raum- und Standortentwicklung) und Ralph Straumann (Informatik) teilgenommen. Das Thema Smart City wurde in parallelen Vortragstracks und mit einem grossen Ausstellungsbereich beleuchtet. An der Konferenz konnte man Details zu vielen (Pilot-)Projekten zu Smart City in Städten und Gemeinden erfahren.

Daten-Layer

Initial begrüsste Konferenz-Initiator Mike Vogt die Besucher. Er präsentierte dabei das SmartSuisse-Modell zu Smart City: mit Untergrund-Layer, Boden-Layer, Luft-Layer und – eben neu im Zentrum beim Thema Smart City – einem Daten-Layer, der sich in die klassische Ebenen-Sicht schiebt, die wir in unserem Fach so gut kennen. In den folgenden Stunden sollte es darum gehen, welche Daten in diesem Daten-Layer erfasst und transportiert werden sollen, wie dieser mit den anderen Layer über Prozesse gekoppelt werden soll und welche Informationen man daraus extrahieren kann.

SBB-Chef Andreas Meyer machte den Auftakt der Referate, indem er unter anderem das Projekt Wolf-Areal in Basel als das smarteste Areal der Schweiz vorstellte. Auf dem Gelände soll in den nächsten Jahren ein smartes Areal konzipiert und entwickelt werden. Er hob weiter verschiedene smarte Themenbereiche rund um die Bahn hervor: Smart Mobility (Mobilitätshubs), Smart Building (Arbeiten mit BIM), Smart Public Space (Design von Erlebnisflächen im Herzen von Städten im Dialog mit der Bevölkerung), Smart City („von isoliert zu vernetzt“, Smart City als Infrastruktur Management Platform bzw. City Information Model (CIM)). Er appellierte an die Schweiz, sich gegenüber den Entwicklungen in anderen Städten der Welt offen zu zeigen, um nicht von diesen überholt zu werden.

Zusammenarbeit und umsichtige Regulierung

Klar zum Ausdruck kam bei verschiedenen Vorträgen das Bedürfnis nach Kooperation zwischen verschiedenen Partnern aus Verwaltung, Wirtschaft und Bevölkerung. Dass die Lösungsentwicklung im Alleingang kaum zu bewerkstelligen ist, wurde beispielsweise im Vortrag von Claudia Pletscher von der Schweizerischen Post deutlich: Sie sah Herausforderungen im Bereich der Regulierung, die der Technologie hinterherhinke. Sie wies in diesem Zusammenhang auf den „Red Flag Act“ im England des 19. Jahrhunderts hin, der für die damals neuen Autos 31 Jahre lang die Maximalgeschwindigkeit auf 4 Meilen pro Stunde (2 MPH innerorts) drosselte und zudem erforderte, das zur Warnung jedem Fahrzeug jemand mit einer roten Flagge  vorangehen musste – nicht ganz unähnlich zu den Settings, in denen heute automatisierte Fahrzeuge erprobt werden. (Übrigens: Der Red Flag Act verhinderte eine stattliche Zahl tödlicher Unfälle nicht.)

Lebensqualität für alle: strategisch versus opportunistisch

In vielen Referaten wurde deutlich, dass die Lebensqualität der smarten Städte im Mittelpunkt steht, oder zumindest stehen sollte. Beispielsweise postulierte Helle Søholt von der dänischen Firma Gehl:

„A smart city is a livable city!“

Damit fand die Bevölkerung der künftigen smarten Städte (die in der Technologieperspektive des Schichtenmodells zwischen Untergrund-, Boden-, Daten- und Luft-Layer vergessen gegangen war) doch zurück auf die Hauptbühne. Dass es diesbezüglich und allgemein für Smart City-Themen in der Schweiz noch Potenzial gibt, wurde ebenfalls in mehreren Vorträgen erwähnt. Thilo Zelt von Roland Berger stellte in diesem Zusammenhang eine interessante Studie zu einem „Smart City Index“ vor. Allerdings fehle es in der Schweiz allgemein noch etwas an klaren Strategien für Smart Cities. Dieser Punkt wurde am zweiten Konferenztag am Treffen der IG Smart City nochmals klar, aber zum Teil etwas anders gewertet: Während manche Städte sich eine Smart Ciy-Strategie gegeben haben (z.B. kürzlich Basel) bzw. eine erarbeiten (z.B. Zürich), haben andere Städte (etwa Aarau) den klassischen Prozess auf den Kopf gestellt (bzw. vom Kopf auf die Füsse?) und direkt mit kleinen Pilotprojekten und Tests gestartet, aus denen sich später eine Strategie herauskristallisiert.

Mobilität: Mehr Intelligenz statt Beton

Das Thema Mobilität war ebenfalls prominent an der Konferenz, nicht zuletzt natürlich mit der Konferenz-in-der-Konferenz Automaticar. Dort referierte Fabienne Perret, Mitglied der Geschäftsleitung von EBP, zum Forschungsprojekt „Einsatz automatisierter Fahrzeuge im Alltag“, das wir zusammen mit diversen Schweizer Partnern zum Thema des automatisierten Fahrens erarbeiten. Daneben drehten sich viele der bezüglich Mobilität genannten Ideen und Konzepte um multi- und intermodale Mobilitätsformen, die mit Hilfe neuer Technologien einfacher nutzbar gemacht werden können. MaaS (Mobiliy as a Service) wurde natürlich zahlreich thematisiert, unter anderem in den Vorträgen von Jörg Astalosch (Italdesign), Sampo Hietanen (MaaS Global) sowie von Gerd Scheller und Martin Fehr (Siemens).

Auch Prof. Carl Ratti vom Massachusetts Institute of Technology (MIT) wies auf die fundamentalen Änderungen hin, die im Bereich Mobilität bevorstehen: In seinem Vortrag zu Senseable Cities zeigte er eindrückliche Ergebnisse der Mobilitätsforschung, unter anderem zum Verkehrsfluss an Kreuzungen. Ausserdem zeigte er auf, dass Infrastruktur heute nicht mehr für 100 Jahre gebaut werden sollte, sondern transformierbar sein sollte, da sich die Bedürfnisse an sie in Zukunft potenziell schnell ändern werden. Das erscheint uns aber zumindest vorerst noch ein hehrer Wunsch, zeigen doch unsere eigenen Forschungsarbeiten in diesem Bereich, wie träge heute viele Bestandteile des Verkehrssystems auf technologische Innovationen reagieren, man denke zum Beispiel an Schiffs- und Flugzeugflotten oder an gebaute Infrastruktur. Künftig wird hier der oben angesprochene Daten-Layer noch wichtiger werden – nämlich um die physische Infrastruktur optimal, sicher und nachhaltig zu nutzen.

Weitere Eindrücke von der SmartSuisse finden sich in den sozialen Medien.

Wir beraten Sie gerne in Fragen rund um den Daten-Layer smarter Städte und smarter Regionen, Datengovernance, nachhaltige Planung und Entwicklung sowie eine Vielzahl weiterer Themen. Wir freuen uns über Ihre unverbindliche Kontaktaufnahme.

 

2018 Esri Partner Conference and Developer Summit – Part 2

The timing worked superbly, like the best Swiss clockwork: A few days before winter made a comeback in Switzerland, I sat in a plane to Los Angeles. Nevermind that California also had slightly cooler temperatures than usual – it was definitely preferable over the polar cold air masses that firmly occupied Switzerland. Even the place names felt evocative: Santa Cruz, Big Sur, and San Francisco. For two weeks I would cruise California, before making my way back to L.A. and then Palm Springs in order to attend the 2018 Esri Partner Conference and Developer Summit together with my colleague, Nicole Sulzberger. In what follows, we describe what we learned during the two Esri events: the latest news about developments at Esri.

Part 1 of this review has been published last week.

The Science of Where

As described previously, The Science of Where is still Esri’s tagline. Esri aims to apply the science of where to help answering spatial questions with:

  • increased efficiency to save resources
  • better analysis to actually understand what is going on, and
  • better communication to foster good decisions

Many of the recent developments shown during the Partner Conference and the Developer Summit can be linked very well to at least one, often several, of these three promises.

 

Select Highlights (continued from Part 1)

Geo AI DSVM

The big news of Esri in terms of data analysis was quite a mouthful: Esri Geo AI Data Science Virtual Machine (DSVM) on Microsoft Azure. That’s „GeoAI DSVM“ for short.  What is behind this? Geo AI DSVM is a virtual machine in the Microsoft Azure cloud that combines ArcGIS Pro and a plethora of Microsoft data science toolkits. It’s part of Microsoft’s „AI for Earth“ project. The VM contains pre-configured installations of, for example, Python, R, VisualStudio, RStudio, Microsoft Powershell, various Python and R packages, Power BI, and a Jupyter Notebook Server. So there is a lot of things that allow you to dive into GIS-supported data science in a scalable cloud environment. In order to use the GeoAI DSVM you need to have an ArcGIS Pro license and Azure VM usage charges apply. An overview of the GeoAI DSVM can be found in the Microsoft Azure Marketplace. On Github, Esri offers an example of a pixel-level landcover classification using Deep Learning with Microsoft’s Cognitive Toolkit, that can be used in conjunction with the Geo AI DSVM.

Geo AI DSVM was a big part of Joseph Sirosh’s (Corporate Vice President in the AI Research group at Microsoft) keynote address:

 

Jupyter Notebooks

Throughout the conference, various data science and machine learning examples were highlighted, and often demonstrated with Jupyter Notebooks – basically an interactive Python environment in your browser that lends itself ideally for making data analysis workflows more transparent and reproducible through integration of code, documentation, and output. Jupyter Notebooks can also be used with the Python API for ArcGIS for, e.g., Portal administration, however, if you are so inclined. If you do data analysis in Jupyter using, e.g. arcpy, results are by default temporary but can be persisted onto a Portal or locally. Esri offers http://notebooks.esri.com for testing Jupyter Notebooks.

One example that was shown using Jupyter was the extraction of SAM sites from orthoimagery using a neural network:

A planned feature for ArcGIS Portal is the integration of Jupyter Notebooks. You will be able to share your Jupyter Notebooks with your colleagues on your ArcGIS Portal.

And Other Things Python

In other Python news, we found an emphasis on ArcGIS Enterprise and Online automation using Python, specifically the ArcGIS API for Python for communicating with a web GIS. Example tasks that can be done through this pythonic API were the creation of groups and user accounts, the assignment of accounts to groups, and of content to users, cloning a portal, re-assignment of content, creation of reports about content, as well as publishing new and pruning old content. The plenary session had an Automation with Python slot that highlights some of the key developments around these topics.

Secondly, Python in ArcGIS Pro was a big topic and also part of the plenary session. Some of the key things to know: ArcGIS Pro comes with Python version 3, rather than 2.7 like ArcGIS 10.x. Further, the Python installation is conda-based. (Ana)conda is a widely used Python package and virtual environment manager that should make the lives of Python developers easier. Thanks to the conda-based installation, many relevant Python packages are pre-installed, for example the whole SciPy stack (this includes pandas). There have been numerous other improvements, big and small, of the Python developer experience, for example for those of you who like to work in Microsoft VisualStudio.

If you want to know more about these topics, check out the videos and the above links: Automation with Python and  Python in ArcGIS Pro.

Exploratory Data Analysis with Insights for ArcGIS

Insights, the data exploration solution by Esri, was highlighted throughout the event (earlier versions of Insights have been shown in previous events). This tool allows to carry out data analysis using a drag-and-drop interface that lets the user build a collection of „cards“ that can contain maps, charts, or tables. Users can interact with different cards using the linked view paradigm where features in a card are highlighted based on a user interaction in another card.

ArcGIS Insights (source: Esri)

Insights further allows joining data dynamically (not sure to what data set size this stays performant) and the analysis that a user builds is represented in a graphical model that can be shared with other users. Since December 2017, Insights is newly available also in ArcGIS Online (previously it was part of ArcGIS Enterprise): To perform analysis in Insights for ArcGIS, users need to purchase a subscription, in addition to an ArcGIS Online Level 2 named user license. A Level 1 named user license for ArcGIS Online provides you view-only access to Insights.

 

Also on the Table

There was much, much more on the plate: improvements around the performance of the GeoEvent Server, the Spatiotemporal Big Data Store and the GeoAnalytics Server, for example, but also in deployment with Docker and Kubernetes, UX and UI, data in the Living Atlas, as well as IoT and real-time applications.

 

And Where Do We Go From Here?

In our opinion, it was rightly emphasised in the plenary session during the conference: the future lies in

  • connecting separate software systems,
  • expanding collaboration between individuals, teams, departments, and organizations,
  • integrating all kinds of data in common views, be they interactive plots and visualizations, feature layers, maps or web scenes,
  • and adding powerful exploration and analysis of data.

In the perspective of Esri, these ingredients enable a new scale in the trajectory of GIS (if you still want to call it that): GIS will turn into a system of systems.

However, this process doesn’t happen by itself but requires careful thinking and designing.

If any of these piqued your interest, please get in touch with us. We are happy to think along with you and assist in designing tomorrow’s workflows, systems and tools!

 

Part 1 of this review has been published last week.

 

2018 Esri Partner Conference and Developer Summit – Part 1

The timing worked superbly, like the best Swiss clockwork: A few days before winter made a comeback in Switzerland, I sat in a plane to Los Angeles. Nevermind that California also had slightly cooler temperatures than usual – it was definitely preferable over the polar cold air masses that firmly occupied Switzerland. Even the place names felt evocative: Santa Cruz, Big Sur, and San Francisco. For two weeks I would cruise California, before making my way back to L.A. and then Palm Springs in order to attend the 2018 Esri Partner Conference and Developer Summit together with my colleague, Nicole Sulzberger, in order to gather the most recent news for our clients and to network with Esri employees and partners from around the world. In what follows, we describe what we learned during the two Esri events: the latest news about developments at Esri.

The Science of Where

The Science of Where is Esri’s tagline since 2017. In the plenary session, Jack Dangermond, the president of Esri, made clear what it summarizes: The world is seeing many big challenges. Loss in biodiversity, competition for resources, increased mobility demands, demographic shifts, and climate change, to name a few. The science of where helps to address all of these and more. It is, in Esri’s understanding, the combination of the competence of geography (process knowledge, spatial thinking and reasoning) and the technology around GIS. Applying the science of where helps answering spatial questions with:

  • increased efficiency to save resources
  • better analysis to actually understand what is going on, and
  • better communication to foster good decisions

All this rings true for me as a geographer and in our team we agreed that this vision matches well with our own.

What Esri showed during the Partner Conference and Developer Summit can be linked very well to at least one, often several, of these three promises, for example:

  • increased efficiency around working with big data, on desktop or mobile, or administrating one’s geodata infrastructure,
  • better analysis capabilities within (e.g., ArcGIS Insights, GeoAnalytics Server) and around Esri’s core products (e.g., GeoAI DSVM, R-ArcGIS-Bridge, Jupyter Notebooks), and
  • better communication through effective visualization (e.g. on mobile using the ArcGIS Javascript API 4.x, using the AR or VR mode and their innovative user experience, or leveraging the computational and graphics performance of game engines for visualizing 3D content)

Select Highlights

ArcGIS API for JavaScript

The developments of the JavaScript API 4.x has been a big topic in this years Developer Summit. The WebApp Builder and the ArcGIS Online and ArcGIS Enterprise Map Viewer are both moving to the ArcGIS JavaScript API 4.x. There are, for example, new out-of-the-box responsive widgets and an enhanced search widget. Feature Layers now support loading large amounts of features for visualization and analysis with improved client-side Web GL-based rendering, improved Feature Service capabilities, and the possibility to build a Feature Layer from in-memory data (such as a CSV file with coordinates that is loaded into a map using drag-and-drop). Finally, in JavaScript API 4.x, the geometry engine is available locally, thus you can get faster responses for geometry operations. This enables us to implement locally (and thus with immediate response), for example, snapping, simple topology checks, interactively calculating areas when cutting polygons and much more.

 

Augmented and Virtual Reality

Augmented (AR) and Virtual Reality (VR) functionality has been built into the ArcGIS Runtime SDK. The AR mode gives a transparent background to a scene so that it can be shown on top of a device’s camera feed. The VR mode allows displaying a scene in stereo and an appropriate VR user interface. There is an Esri Labs ArcGIS 360 VR app for the Samsung Gear VR headset on Oculus that highlights the new VR capabilites of Esri software. Further, Esri showed their tabletop UX for planning: there, a 3D scene (from e.g. City Engine) is displayed on a virtual tabletop. Viewers can virtually gather around the table and interact with the model, e.g. selecting different planning scenarios for visualization. The viewers themselves can be in remote locations. Upon viewing the scene they can also see other viewers and what they are looking at. Finally, any viewer can teleport into the scene itself and look at the model from different in-scene vantage points.

The following video from the plenary sessions highlights some AR/VR capabilities of ArcGIS Runtime (jump to 4:00 for seeing first a VR, then an AR demo):

 

3D and Indoors GIS

Esri 3D Web Scenes will be consumable on mobile devices, using a responsive interface. Features from 3D scene layers are quickly streamed to the device. Users can use advanced measurement tools to, for example, measure plan surface areas in a 3D scene:

 

Some powerful 3D features in native apps such as interactive line-of-sight analysis have been shown in another plenary session, the video of which is available from Esri.

Further, 3D scenes support a new rendering mode that gives building edges a „sketch“ look. This is interesting, for example, for visualization of planned projects where you do not yet want to convey a very crisp and precise impression of a provisionally planned scenario.

Since the previous Partner Conference and Developer Summit, ArcGIS Indoors has matured further. This new suite of tools comprises ArcGIS Indoors Desktop (built on top of ArcGIS Pro if I’m not mistaken), the ArcGIS Indoors Web Viewer, and the ArcGIS Indoors Mobile App. They in turn support data preparation and map design, simple editing and dashboard functionality, and indoor-navigation using device sensors through the indoors positioning feed.

ArcGIS Indoors: Esri Campus Viewer (http://3dcampus.arcgis.com/EsriCampusViewer/app)

When you zoom out from your building(s) view, the transition into geographic space and navigation by GPS only should be seamless. The navigation functionality relies on an appropriate 3D network dataset (somewhat in contrast to our own pedestrian modeling tool Walkalytics).

Click through to Part 2 of this review.

 

Mobilität und Erreichbarkeit: Business und Location Intelligence

Mobilität wird immer wichtiger: Pendeln zur Arbeit, Einkaufen, Ausflüge oder Besuche bei Freunden. Nicht nur für Privatpersonen sondern auch für Firmen ist die Mobilität und damit zusammenhängend die Erschliessung ein wichtiges Kriterium in vielen Fragestellungen.

Wo soll das Filialnetz verdichtet werden? Wo sollten wir unsere Standorte konsolidieren? Welche Anreize sollten wir setzen, damit unsere Mitarbeitenden möglichst per ÖV pendeln? Soll der Firmensitz eher in Aadorf oder in Bedorf zu liegen kommen? Wo erreichen wir unsere bestehenden Kundinnen und Kunden am besten? Wo finden wir neue Kundschaft? Und wo sind wir in Reichweite der meisten qualifizierten Arbeitnehmenden für unser Geschäft? Alle diese Fragen und noch mehr können wir mit unserer Expertise in den Themen Datenanalyse, Geoinformationssysteme und Mobilität beantworten.

Mit unseren Datengrundlagen und geeigneten Services können wir Fahrzeiten (MIV oder ÖV) und Gehzeiten zwischen Standorten bestimmen, im sogenannt belasteten Netz (d.h. mit dem zu erwartenden Verkehr) oder im Idealzustand. Für Gehzeiten benutzen wir unseren bewährten Walkalytics-Ansatz, der sich auf der ganzen Welt einsetzen lässt (falls Sie damit noch nicht vertraut sind: www.walkalytics.com bzw. unsere Blogposts zum Thema geben Ihnen vertieften Einblick).

Das pulsierende Herz des Wirtschaftsmotors: Die über den Tagesverlauf animierten MIV-Isochronen (15, 30, 45 und 60 Minuten) von Zürich

Basierend auf Wegzeiten können Gebiete gleicher Fahrzeit, sogenannte Isochronen, ermittelt werden. Im Bild oben sind hell- bis dunkelrot Gebiete abgebildet, die von der Quaibrücke in Zürich mit dem Auto innert 15, 30, 45 und 60 Minuten erreicht werden können. Die Animation zeigt, wie sich die erreichbaren Gebiete über den Tagesverlauf wegen der unterschiedlichen Verkehrsverhältnisse verändern.

Natürlich können wir mit unseren Geoinformationstools noch weitergehende Analysen durchführen – zum Beispiel:

  • Mit Daten aus Ihrem CRM-System können wir die Anzahl bestehender Kunden oder potenzieller Kunden ermitteln, die Sie innert einer gewissen Zeit erreichen können bzw. die Ihren Standort erreichen können. Potenzielle Kunden können z.B. Personen sein, die wichtige Merkmale Ihrer bestehenden Kunden teilen.
  • Wenn Sie von einem Filialnetz aus verschiedene Kundenstandorte (z.B. Liegenschaften im Fall einer Immobilienverwaltung) betreuen, können wir die optimale Zuordnung von Kundenstandorten zu Ihren Filialen ermitteln.
  • Wir können Verkehrsmittel miteinander vergleichen zur Minimierung der Reisezeit Ihrer Aussendienstmitarbeitenden oder zur Verbesserung der Umweltfreundlichkeit des Pendelverkehrs Ihrer Mitarbeitenden.
  • Schliesslich können wir Expansionsplanungen, Standorteröffnungen oder -verschiebungen dahingehend untersuchen, ob sie Ihr Kunden- und Arbeitskräftepotenzial optimal nutzen (das Beispiel rechts zeigt die Anzahl der innerhalb einer gewissen Zeit erreichbaren 25- bis 29-Jährigen).

Haben wir Sie neugierig gemacht? Gerne beraten wir Sie unverbindlich bezüglich Ihrer Fragestellungen.