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.

 

 

2017 Esri Partner Conference and Developer Summit

From Swiss late winter to Southern California spring: My colleague Alex Graf and I attended the 2017 Esri Partner Conference and Developer Summit in Palm Springs two weeks ago. These events are always a great opportunity to get the latest information on Esri software and strategy as well as spend a week in an inspiring ‚geo-rich‘ environment. In this post, we summarize some highlights from the conference.

The motto of the Partner Conference and the Developer Summit was Esri’s new claim: „The Science of Where“. Yet what exactly is the „Science of Where“? In a nutshell: It uses location and technology to collect, analyze, visualize and share data and information to solve relevant problems. Or in Jack Dangermond’s words: „[…] The Science of Where is, quite simply, what we do.“ That „we“ includes us as geographers, data scientists, developers, and, of course, users of the ArcGIS platform. From that point of view I really like the slogan. Unfortunately (but understandably) Esri has trademarked it, so this won’t become an inclusive rallying cry for e.g. #gistribe.

The big trends

The big trends in IT are of course also very relevant for GIS, and some were covered in depth at the Developer Summit: Distributed (GI) systems, real-time data streams, big data and the Internet of Things (a bit less than the other ones). Since a couple of years, Esri has been claiming to provide a distributed platform for GIS. While in the beginning this was more of a marketing claim than a working solution, we now welcome a phase where the claim becomes more and more credible. With ArcGIS 10.5, portal-to-portal collaboration is possible, for example, which allows you to connect different GI systems and share data across organizations.

Esri has also made a huge effort to enable their technology to work with ever bigger data, particularly data being transferred in real-time data streams. One outcome of this effort is the new spatio-temporal big data-store. The data store is not only capable of a much higher write-throughput (according to Esri about 50 times more events per second can be processed compared to a classical geodatabase); it can also be scaled across multiple machines in order to increase capacity. Esri also introduced their new offering for analytics: the GeoAnalytics server. It is intended for distributed analysis of massive vector and tabular data including temporal information. It should also be easily scalable and allow you to shorten the processing time of some of your analyses massively. Last but not least, visualization is also improved to work smoothly with big data (check out this tweet for an example).

All these improvements in technology will support the shift from simple GIS apps for displaying and querying spatial data to more advanced solutions that support advanced exploration, finding patterns and making predictions.

Say goodbye to old friends (or foes, frenemies)

The technological advancement has of course implications for Esri’s product portfolio: Esri believes that using ArcGIS Server as a standalone software and accessing services via REST will be a less and less common practice. They expect that the typical user (if such thing exists) will rather use services via Portal for ArcGIS. Consequently, Esri has bundled ArcGIS Server together with Portal for ArcGIS,  ArcGIS Data Store and the ArcGIS Web Adaptor and gave this package the new product name ArcGIS Enterprise.

Moving the focus from server to desktop, another oldie you should start saying Goodbye to is the ArcMap/ArcCatalog combo. ArcGIS Pro is now not only the future but should also really become the present. If you haven’t already started working with it, you should definitely do that now! There will be another release for ArcMap, but that will be purely bugfixes. All new development goes exclusively into Pro. More importantly, feature equivalency will be „more or less“ achieved this year – note though: some ArcMap/ArcCatalog functionality might never be included in Pro. Just keep an instance of ArcMap available somewhere for that odd task that you can’t do in Pro, but use Pro for everything else. And there are of course more and more cool things that you could never do in ArcMap, for example creating vector tiles, now also in 3D!

Some other cool stuff

Speaking of 3D: It was really one of the big topics at the Developer Summit (like every year to be honest – 3D provides really cool demos, doesn’t it? See this story map for an example). 3D is available across the Esri platform and all SDKs now support the same 3D capabilities. This means that you soon can use 3D scenes offline on a mobile phone! – and the performance during the demo looked exciting.

In 2016, Esri announced Insights which has now been released. It’s a browser-based tool for exploratory analysis of spatial and non-spatial data. It has similarities to business intelligence (BI) tools (cough, Tableau, cough, qlik, cough), but definitely with a stronger focus on geospatial analysis. Somewhat surprisingly, Esri stated that they don’t see themselves in competition with other BI tools. In any case, it will be interesting to see how Insights will establish itself in the market and where and to what ends it will be used (keep in mind that you’ll need an ArcGIS Enterprise installation to use Insights). For now the app works with vector and tabular data only. Support for raster data is announced for fall 2017.

Another newcomer is the ArcGIS API for Python. This API is much more powerful than the existing arcpy module and lets you script and automate all kinds of tasks across the Esri platform. Esri branded it (tongue-in-cheek) as the „return of AML“. This should delight at least one of my colleagues at EBP. There is also a completely new language called Arcade. Arcade is designed to formulate expressions (think for example, labeling) in a consistent way across the platform, something that was not possible with the options available now.

To finish off this post, let’s take an exciting look into the future: Watch this video of Esri’s HoloMap, a prototype app for Microsoft’s HoloLens:

Offline Editing with ArcGIS

We are currently working on a mobile app with offline geodata editing capability. The idea, of course, is: Users collect and edit data in the field and synchronise changes back into a central database when they return to their offices. The ArcGIS platform provides all the tools to easily implement that functionality. The necessary configuration is described in this tutorial. However, if you use your own app instead of Esri’s Collector app, you have to consider a few additional points. You could find out about these on help sites. But to keep you from searching too long I’ll share them in this post.

Offline geodata collection and editing with ArcGIS can facilitate railroad track maintenance
Offline geodata collection and editing with ArcGIS can facilitate railroad track maintenance

Challenges … – and a solution

We basically had two challenges to solve:

  • How do we bring the edits that were made outdoors back into the DEFAULT version of the database?
  • How do we get rid of all the (in this context: superfluous) versions the offline sync creates?

A look behind the scenes is helpful to understand what’s going on: For offline synchronisation in the Esri ecosystem you first need an enterprise geodatabase. The feature classes can either be versioned, or non-versioned with archiving activated. In our multi-user environment the second option was not viable, thus we had to go with versioning. You can find more information about setting up your environment here.

When a user then downloads data from a feature service, the following happens: The database creates a new version that is derived from the DEFAULT version. This new version gets a name like username_ID (for example Esri_Anonymous_i_1466000080844 if your map service is not secured). ArcGIS then creates a replica based on this version. This is a file geodatabase that is stored on the mobile device. One more important detail: In the database the replica is a child version of the originating version. This „hidden version“ is invisible with the normal ArcGIS tools. You can only see it in the SDE.VERSIONS table where it appears with a name like „SYNC_“.

After offline editing the user starts the synchronization process. However, this does not yet bring your edits back to the DEFAULT version of the database. Synchronize only reconciles the data between the replica and the originating version. Afterwards you need to use the Reconcile Versions tool to finally see your edits in the DEFAULT version and hence your map service. In order to streamline this process, for our application we created a geoprocessing service based on the Reconcile Versions tool which the mobile app calls after synchronization is complete (see also this help page).

Addendum for maintaining performance

The above process works fine. But there is, as you may know, one flaw: The database versions don’t automatically disappear but keep piling up. This can become a problem, when the version tree is big – which makes database compression inefficient. In the end (certainly in our project with several hundred versions), you can end up with an incredibly slow database. So let’s get rid of those unnecessary versions as soon as possible!

The Reconcile Versions tool has an option to delete version afterwards. Unfortunately, the tool fails consistently with the error message „Error deleting version […] Operation not allowed on a version with dependent children“. But there are no child versions visible in ArcGIS. So what gives? Of course, the problem arises from the „hidden versions“ of the replicas that keep us from deleting their parent versions. And how do we eliminate those? First of all, by unregistering the replicas using the REST interface of ArcGIS Server. But in our case it turned out that this was not enough: Somehow we have some „SYNC_“ versions that do not have a replica registered on ArcGIS server. Where these come from I am not entirely sure. Maybe they are created when a user aborts the data download from the map service? In any case, you can remove those versions using the Delete Version tool – although they are not visible in ArcGIS Desktop. You just need to find the version names using either arcpy.da.ListVersions or a query on SDE.VERSIONS.

The overall workflow in the end looks like this:

While the ArcGIS platform provides a great ecosystem, there are some murky corners where things can become convoluted – as in every GIS ecosystem, let’s face it. I hope these tips help you better understand offline editing and synchronization. If not or if you have an even trickier problem to solve, my colleagues and I are happy to take your questions, or hear your experiences.

LoRaWAN: IoT Network for the Future?

If you follow someone from #TeamEBP on Twitter, you may have noticed that last week we installed a LoRaWAN gateway of The Things Network in our office building. And like some of my colleagues you may have wondered (or wonder now): What is this all about?

Is EBP now into selling parrots (of course we could call our parrot Polly, not Lora)? Or are we supporting an alternative Zurich radio station? Good guesses. But it is of course neither of those two: LoRaWAN stands for Long Range Wide Area Network, a technology for low power wireless telecommunication networks. LoRaWAN gateways are intended to be used by battery operated sensors and other low power devices, nowadays better known as the Internet of Things (IoT), to transfer their data to the internet.

While mobile and WiFi networks drain your mobile phone battery quickly with increasing data transfer rates, LoRa takes the opposite approach. Only very little data can be sent over the network to minimize power consumption. Take for example the optimizing of garbage collection by installing sensors on waste bins, a solution that is already more widespread than I expected. You would certainly use batteries, maybe combined with energy harvesting, rather than connect every garbage container throughout a city to the power grid.

450px-HVogel-FrauHolle

Have you ever noticed the amazing anticipation of IoT ideas in „Frau Holle„? Bread calling out: „Oh, take me out. Take me out, or I’ll burn. I’ve been thoroughly baked for a long time.“ (Image source: Public domain).

LoRaWAN Gateways serve as transparent bridges for the end-to-end encrypted communication between sensors and devices out in the field and central network servers (you can read more about the technology here). One big advantage of LoRa is that you only need a few of these gateways to cover a whole city.

While commercial companies are working on LoRa networks (e.g. Swisscom or Digimondo), the afore-mentioned The Things Network (that now EBP is a part of) is an interesting open initiative. With The Things Network, an enthusiastic community is building LoRa networks in cities all around the world. These networks are free and open to use for everybody. At EBP, we immediately felt favourably towards that idea and are excited to share some of our company’s bandwidth with the community behind The Things Network.

The Things Network Zurich coverage map with the EBP gateway
The Things Network Zurich coverage map with the EBP gateway

As an additional benefit, we thus expand our playground to experiment with IoT and new networking technologies. Our order for additional hardware to build some LoRa test devices is out and we are looking forward to do some soldering. So stay tuned for more LoRa news here. Or indeed, join the revolution yourself!

Alle Wege führen zu Windows 10 – und Azure

Sprichwörtlich führen alle Wege nach Rom. Nach meinem gestrigen Besuch des Technology Outlooks von Microsoft Schweiz scheinen in Zukunft aber alle Wege zu Windows 10 zu führen. Oder in den Worten von Microsoft: „Wherever your code was born, you can bring it to Windows“. Welche dieser Wege Autobahnen und welche eher holprige Wanderpfade sind, wird sich zeigen.

clouds

Mit Windows 10 setzt Microsoft konsequent auf eine Plattform für alle Geräte: Überall läuft die gleiche Runtime, die Apps kommen für alle Geräte aus einem Store und werden mit Visual Studio entwickelt. Der gleiche Code läuft auf PCs, Tablets, Phones, Hololens oder auf einem Raspberry Pi 2. Spannend daran ist, dass mit Windows 10 ein adaptives User Interface zur Verfügung steht: Man entwickelt eine Benutzerschnittstelle, die sich dann automatisch ans jeweils angeschlossene Display anpassen soll. Wenn man sein Windows Phone also an einen Bildschrm anschliesst, sehen die Applikationen aus wie auf dem PC, statt einfach das Handy-Display zu skalieren. Um das zu testen, müsste man allerdings zuerst mal ein Telefon mit Windows haben…

Dieses Problem hat Microsoft ebenfalls erkannt. Um Windows Phones attraktiver zu machen und den Rückstand bei der Anzahl verfügbarer Apps zu verkleinern, bieten sie mit Windows 10 (einfache?) Möglichkeiten, Android- und iOS-Apps auf Windows 10 zu bringen. Für Android-Apps gibt es einen Emulator – der gleiche Code kann also weiterverwendet und mit spezifischen Windows-Funktionen ergänzt werden. Für iOS-Apps ist eine Neukompilierung des Objective C-Codes notwendig, was von Visual Studio unterstützt wird. Solche „Bridges“ zu Windows 10 gibt es übrigens auch für Win32- und Web-Applikationen. Die Wege führen nicht nur zu Windows, sondern auch wieder heraus: Beispielsweise durch die Integration von Xamarin in Visual Studio 2015, um Apps plattformübergreifend zu entwickeln. Oder durch den .NET Core 5 für Linux und Mac OS X.

Ein Stolperstein für diese schöne neue Welt könnten die unterschiedlichen Fähigkeiten der Geräte sein. Einerseits natürlich die Rechenleistung, andererseits die unterschiedlichen Bedienkonzepte und Spezialfähigkeiten – die Hololens unterscheidet sich doch stark von einem PC. Trotzdem ist Windows 10 sehr spannend und vielversprechend. Wir freuen uns jedenfalls auf die neuen Möglichkeiten.

Im zweiten Teil der Veranstaltung präsentierte Sascha Corti, Technical Evangelist von Microsoft Schweiz, die Verwendung von Microsoft-Lösungen für das „Internet of Things“ (IoT). Für uns bei Ernst Basler + Partner ist das natürlich speziell interessant, da auch wir bereits entsprechende Lösungen entwickeln.

Oft werden im Zusammenhang mit IoT abstrakte Ideen entwickelt oder grosse Luftschlösser gebaut – wie üblich, wenn ein Thema ganz oben auf dem Hype Cycle ist. Microsoft sieht das IoT aber pragmatisch: Schlussendlich geht es einfach darum, Informationen von Geräten über Netzwerke auf eine zentrale Plattform zu bringen. Dort analysiert und visualisiert man die Daten, um für sein Geschäft einen Mehrwert zu generieren und bessere Entscheidungen treffen zu können. Das alles ist mit vorhandener Technologie problemlos möglich. Idealerweise beginnt man deshalb mit Geräten und Daten, die bereits zur Verfügung stehen. Die daraus gewonnen Einsichten kann man anschliessend laufend durch zusätzliche Geräte, Messungen und Daten verbessern.

raspberry

Als ideale Plattform zur Analyse und Darstellung von IoT-Daten sieht Microsoft natürlich Azure. Tatsächlich steht hier out-of-the-box eine breite Palette von Möglichkeiten zur Verfügung, um typische IoT-Workflows abzubilden: Datenspeicher, Datenmanipulation, Analyse, Darstellung. Aus unserer eigenen Erfahrung können wir bestätigen, dass sich Lösungen damit sehr einfach umsetzen lassen. Ein weiteres Argument zur Nutzung der Cloud ist die Fähigkeit zur Verarbeitung unglaublich grosser Datenmengen: Eine Instanz eines Event Hubs kann bis zu 1 Gigabyte Daten pro Sekunde von 1 Million unterschiedlicher Quellen verarbeiten (insgesamt verarbeiten die Events Hubs momentan mehr als 60 Terabyte Daten pro Tag).

Zum ersten Mal live gesehen habe ich gestern Azure Machine Learning. Spontan fand ich das sehr eindrücklich – allerdings nicht ganz ungefährlich. Eindrücklich ist, wie einfach sich hier Analysen erstellen und durchführen lassen. In einer graphischen Oberfläche klickt man sich einen Workflow zusammen (ähnlich wie beispielsweise in FME), wählt eine geeignete Methode und trainiert diese. Ein Knopfdruck publiziert das trainierte Modell als Web-Service.

Warum kann das gefährlich sein? Es ist so einfach zu bedienen, dass man auch ohne Kenntnisse in Datenverarbeitung, Statistik und Machine Learning schnell zu Ergebnissen kommt. Die Frage ist bloss, ob es die richtigen Ergebnisse sind. Um zu geschäftlichem Mehrwert und besseren Entscheidungen zu gelangen, ist das allerdings zentral. Man sollte deshalb nicht nur wissen, wie man mit dem Werkzeug umgeht, sondern auch was man damit macht. Dazu gehört das Wissen über die verwendeten Daten genauso wie Kenntnisse der eingesetzten Methoden.

 

 

 

Let there be light: Data visualization with SAP Lumira

GIS and Business Intelligence (BI) are buzzwords you hear together increasingly often (see also our articles on GISconnector, which we consider a low-cost, easy-entry BI solution). Inspired by this article from iX magazine I decided to have a look at the „self-service BI“ solution SAP Lumira. Lumira is an analysis and visualization tool and SAP offers a freely downloadable version. There is also a standard edition with more features that sets you back almost 1,000 $. The workflow in the application is simple: You import some data and prepare it, create visualizations and publish them.

map

Data Source for all visualizations: World Bank (© 2010 The World Bank Group)

Prepare
In the free version you can use Excel Sheets, CSV data, copy data from the clipboard or connect to a SAP HANA One database. The full version also lets you access databases with SQL queries. For my trial I found an Excel table about global energy use provided by the World Bank (downloaded from www.visualizing.org). After loading the data you can prepare it for the visualization: Filter, calculate new values or join different datasets together.

You can also create a so-called geographic hierarchy to visualize the data on a map. A geographic hierarchy is a kind of geocoding: Geographic placenames are matched with an internal database to add location to your data records. The good thing is, that it clearly identifies records that could not be automatically matched. It then offers you the possibility to select possible matches from a list. Unfortunately, you can only choose from this non-extendable list. For some reason it did not suggest Slovakia as match for Slovak Republic which would have left changing the country name in the input data as the only remaining option. Luckily, I had also country codes in my dataset which worked much better and are obviously better practice, if you have them available.

geohierarchy

 

Visualize
Now comes the really cool part: Drag and Drop visualization. Just select one of the many available charts, drop your measures and dimensions on the X and Y axes, apply some filters on the data and your diagram is ready. This is really comfortable (and I can tell, having recently spent hours producing some rather simple graphs with R and ggplot).

Apart from classic graphs you can also create maps. These are nice for a first impression, offering zooming, panning and mouseover information. But overall the maps are pretty basic with almost no options to influence the display. The full version offers the possibility to use ArcGIS Online maps which brings a broader range of functionality.
For my trial I tested only simple visualizations. But Lumira also offers some fancier variants e.g. heatmaps, network diagrams or tagclouds.

Compose
After creating visualizations to make your point, you can aggregate them into a report or a „board“. The nice thing is that the charts remain interactive. I haven’t yet tried all possibilities but you could probably do similar things as with storymaps.

Share
The next step is to make your visualizations available for others. Unfortunately there is (at least in the free version) no option to export the graphics as PDF or image files. This would be useful in order to be able to include the graphics in reports and presentations.

One possible solution to this is to upload your board to the Lumira Cloud. That is very neat and you can then provide access to individual users or the whole world. proved to be an unexpected hassle and you can only enjoy my screenshots for the moment.

A few words about the data

energyUse
For this little test I was more interested in the tool than in the data itself. Some things look quite interesting though. Whereas the per-capita energy consumption for most countries has increased between 1970 and 2005, Luxembourg shows a massive decrease. My first hypothesis for the cause of this unexpected outcome is the demise of the heavy industry, but I have not yet found a confirmation for this. Perhaps you, dear reader, know more?

Event-Processing mit FME Server: Zugverspätungen als Push Event

Da unser Bürohaus gleich neben dem Bahnhof Stadelhofen liegt, erreicht man die S-Bahn in einer Minute. Wenn man nun schon am Schreibtisch wüsste, dass der Zug Verspätung hat, könnte man also noch etwas länger sitzen bleiben. Und so eine Nachricht wäre sicher auch nützlich, wenn man an einem anderen Ort unterwegs ist…

dampflokomotive

S-Bahn vor der Erfindung von Smartphones 😉

Da mein iPod auch bei längeren Wartezeiten zuverlässig für gute Unterhaltung sorgt, muss ich zugeben, dass mir die paar Minuten Wartezeit auf einen verspäteten Zug nichts ausmachen. Ausserdem gibt es schon nette Apps der SBB, welche einen über die Verspätungen ausgewählter Züge (und vieles mehr) informieren. Als Übungsanlage für unseren internen Creativity Day war die Aufgabenstellung oben aber ganz gut geeignet, um einige Dinge auszuprobieren: Event-Verarbeitung in FME Server, Azure, Pushover,…

FME ist eine Software zur Format-Umwandlung, Prozessierung und Überprüfung von räumlichen und nicht räumlichen Daten. Format- und Modelltransformationen können in sogenannten Workspaces definiert werden. Zur Transformation von Daten führt man den Workspace entweder in einer Desktop-Applikation (FME Desktop) oder auf einem FME Server aus.

In der Vergangenheit konnten Workspaces in FME Server entweder durch eine Benutzerinteraktion oder zu vordefinierten Zeiten gestartet werden. Seit FME Server 2012 ist es möglich, die Ausführung von Workspaces durch Ereignisse auslösen zu lassen. So ein Ereignis kann alles mögliche sein: ein Messwert eines Sensors, die Positionsmeldung einer Smartphone-App aber auch eine einfache E-Mail. FME Server unterstützt verschiedene Protokolle, über welche Ereignisse übermittelt werden können. Davon ist HTTP wohl für viele Anwendungen die naheliegendste Lösung.

Für die Abfrage der Verspätungsmeldungen haben wir einen recht einfachen Workspace entwickelt. Zuerst ermitteln wir die nächste ÖV-Haltestelle zu einem Punkt, der in unserem Fall die Positionsmeldung eines Smartphones ist. Mit dieser Information fragen wir den Dienst transport.opendata.ch ab (weitere Infos), um den Fahrplan bzw. die Verspätungsmeldungen für diese Station zu bekommen. Wenn Verspätungsmeldungen vorliegen schicken wir diese per Push-Nachricht an das Smartphone.  Dafür haben wir den Dienst Pushover genutzt.

pushover

Aus unserer Sicht stechen vor allem zwei Stärken der Event-Prozessierung mit FME Server hervor: Einerseits können Ereignisse mit einem Raumbezug sehr einfach verarbeitet werden, da die ganze Palette von FME-Werkzeugen zur Verfügung steht. Andererseits ist ist die Entwicklungszeit sehr kurz: Für den oben beschriebenen Prototypen haben wir rund einen Tag aufgewendet, wobei in diesem Aufwand der Aufbau der Infrastruktur enthalten ist.

Potenzial für den FME-Einsatz sehen wir vor allem bei Fragestellungen mit Geofencing. Der „Geofence“ – ein virtueller Zaun – definiert dabei ein bestimmtes Gebiet. Wenn darin ein bestimmtes Ereignis auftritt, löst dies eine Aktion aus. Beispielsweise kann ein System eine Benachrichtigung senden, wenn ein Objekt den Geofence betritt oder verlässt.

Übrigens: Esri unterstützt ab ArcGIS 10.2 ebenfalls Events. Darüber berichten wir vielleicht zu einem späteren Zeitpunkt mal.

PS 1: Many thanks to Safe: Firstly for providing us with a demo license to try out events and notifications in FME Server ourselves. Secondly to Steve from the Safe support team for providing us with a very quick answer to a configuration issue.

PS 2: Zum Schluss noch eine kleine Werbung in eigener Sache: Ich wurde von Safe als „FME Certified Professional“ zertifiziert.

Web Scraping von Wikipedia-Koordinaten

Wikipedia ist eine fast unerschöpfliche Informationsquelle: Die deutsche Ausgabe umfasst mittlerweile mehr als 1.5 Millionen Artikel. Wenn ich jeden Tag 100 Artikel daraus lesen würde, wäre ich ungefähr für die nächsten 40 Jahre beschäftigt, sofern keine neuen Artikel hinzukämen. Aus geographischer Sicht bemerkenswert und möglicherweise nicht so bekannt ist die Georeferenzierung von vielen Artikeln. Im WikiProjekt Georeferenzierung werden Lageinformationen für Wikipedia-Inhalte bestimmt. Mittlerweile gibt es deshalb in der deutschsprachigen Wikipedia über 340’000 Koordinatenangaben.  Beispielsweise sind neben den Artikeln für Städte oder Berge auch Artikel zu Bauwerken georeferenziert. Die Koordinaten eines Orts sind jeweils oben rechts eines Artikels zu finden. Praktischerweise kann man sich den Ort auch gleich auf einer Open Street Map-Karte anzeigen lassen.

millionenstaedte307 Millionenstädte gemäss Wikipedia

„Web Scraping von Wikipedia-Koordinaten“ weiterlesen

FME World Tour 2011

Die Software FME (Feature Manipulation Engine) von Safe Software ist ein mächtiges Werkzeug, um Geodaten  aller Coleur zu laden, transformieren und speichern. Anstelle einer grossen Anwenderkonferenz organisiert Safe Software die FME World Tour 2011 mit Stationen in verschiedenen Ländern. Das schont nicht nur das Portemonnaie, sondern auch die Umwelt. Statt nach Vancouver ging ich deshalb letzte Woche nach Fribourg zum Schweizer Event der World Tour. Rund 70 Personen nahmen an diesem Erfahrungsaustausch teil.


„FME World Tour 2011“ weiterlesen