Design considerations for a Geospatial Intelligence App and it should be Qt.
A Geospatial Intelligence App empowers the analyst to gain insights by analyzing spatial information and therefore should be designed with map centric workflows in mind.
Functional requirements
In general, data can be seen as information collected by observing real world events. Data only offers a small point of view and you cannot see the big picture by just focusing on this small extract. You have to put all the available information in a bigger context. Data having spatial information can be easily visualized in a map and the map defines the bigger spatial context. Quality assured maps define the spatial ground truth for any spatial analysis.
As a geospatial analyst I want to use quality assured maps.
So that, I can be sure of my spatial analysis being sustainable.
A map consists of different thematic layers. Each layer can be turned on and off and is drawn independently with the map. Reference layers define the geographic context of a map. For example the context can be topographic, human geographic, geopolitical, oceanic and so on or just collaborative like OpenStreetMap.
As a geospatial analyst I want to switch between different reference layers.
So that, I am able to change the geographic context of my map view.
Operational layers usually represent real world objects and events modeled as features having various properties. From an intelligence perspective there is a need of visualizing worldwide human activities as an operational layer.
As a geospatial analyst I want to visualize human activities in a operational layer.
So that, I can gain insights about what is happening in every corner of the world.
Getting technical
When designing an app these days you follow a mobile and cloud first strategy. The front-end should be optimized for mobile displays and the app is using a backend which is hosted in a cloud based infrastructure.
In the 90’s the “Green Team” developed a virtual machine which was able to run byte-code by providing a no-cost runtime for the most popular platforms. The mascot was named duke, the company name was Sun, but desktop development was no fun. Java offered platform independent APIs and GUI toolkits for desktop development.
They started with the Abstract Window Toolkit (AWT) designed as a thin layer abstracting the underlying native operating system user interface. The next toolkit was Swing offering richer widgets and a model view controller (MVC) design. Swing widgets were drawn using Java 2D technology and offered a look and feel based on plugins. By the way “Big Blue” developed a Standard Widget Toolkit (SWT) which accessed the native operating system user interface and being used by a famous IDE named Eclipse. Right now, another toolkit formerly knows as Java FX is intended to replace Swing in the near future. But, when you take a look around you do not find many desktop applications being developed using Java and there are various reason for it.
Manager: “Write once, Run anywhere.“
Engineer: “Write once, Read twice (Code Review), Ship thrice (Linux, Mac, Win), Debug many times (Production is evil).”
There is a trend using progressive web apps for mobile and desktop development. Electron allows the development of desktop apps using web technologies. It combines the chromium rendering engine and the Node JS runtime in a somewhat client-server architecture. This reminds me of the weird Applet and ActiveX architectures from the 90’s. Developers were trained to deliver high quality desktop apps using the UI components which were shipped with the operating system. Time to market is crucial, so you had to plug your UI components into the browser.
Manager: “It is exactly the other way round. You just need to use TypeScript with a bunch of cutting edge web frameworks running in chromium and NodeJS to deliver high quality progressive web apps.”
Engineer: “Nope, it is just weird!” — “PWA means Progressive Weird App!”
If you only target the Win platform — in the context of desktop apps there is good reason for doing so, call it market share — you started with the native Win API or the wrapper around it being named Microsoft Foundation Classes (MFC) in the 90’s. We should not forget about Win Forms which was used by dozens of Visual Basic developers. In 2002 the .NET Framework entered the stage and was offering language interoperability and a common language runtime. Today, if you want to target Linux, Mac and Win there is another option in town better known as .NET Core offering a platform independent API. For native desktop development we know about Win UI targeting Win only and for multiplatform support offering UI forms there is Xamarin. VS Code and MS Teams are being developed with Electron and so we hope that someone from Redmond is showing some love to a multiplatform native lag free UI toolkit.
In the past I only got my hands dirty with some demos for the Mac using the Cocoa framework. It feels like developing for Win by using the MFC in the 90’s and yes Swift is a nice way to replace Objective-C. But, don’t get me wrong I really like this kind of entry threshold which keeps the unexperienced developer away from creating bad designed and unstable apps for the end users.
“Mac is for the cool guys wearing sneakers and big respect to anyone who delivered a production ready app using Cocoa and Objective-C.”
Do we ran out of technologies yet? No, we don’t!
A long time ago in a kingdom far, far away… — if you take a look on a map you will easily see that Norway is not that far away from Germany — a company named Quasar Technologies designed an open source widget toolkit for multiplatform development being based on C++.
“When based on C++ it is, be very skilled you must, young Padawan.”
The first two versions of Qt were only shipped for the Unix and Win platform. Since then, Qt was released for various other platforms targeting mobile, automotive and embedded devices. A skilled developer can easily implement the business workflows using C++ and offer a neat UI by using QML (also known as the better HTML) and JavaScript. Qt is offering a kind of model view controller approach being very similar to the Java Swing implementation. Surprise, surprise both toolkits were designed at the same time. The new Qt Quick controls offer various styling options using color accents which makes designing an app following a visual key a breeze.
“When excellent user experience you reach, implement native look and feel rendering you will.”
With a toolkit being based on C++ there is no automatic garbage collection out of the box. I think automatic garbage collection was first introduced by Lisp in the 50’s — big clap to the Lisp creators. Qt offers a kind of parent child memory management concept. When the parent instance is deleted all the child instances are also deleted and the memory shall be freed. By implementing data complex workflows you will easily recognize that you have to think about memory management and how the data should be laid out in memory. From my personal experience, automatic garbage collection works fine if you have to fight task complex workflows like being used in these enterprise ready webservices architectures. It is not a surprise that Java was and maybe Go is in high demand for enterprise ready webservice development.
Taking a look back at the functional requirements formulated as user stories: There is no such need for automatic garbage collection, now!
“An engineer uses the skillset for knowledge and technical excellence, never for attacking the infrastructure with unnecessary garbage.”
Summary
Our Geospatial Intelligence App should target multiple platforms, should be easily customizable and should not rely on automatic garbage collection.
We are going to show some love to an European Technology Stack based on C++ and we hope it is Qt.
