Embedded GIS: Joint processing of attribute data and geodata

The combination of factual and geodata processing in one application could prove to be a key feature for future development environments. Anyone who is professionally involved with attribute data and geodata has probably asked himself these two questions more than once: Why are Geographical Information Systems (GIS) structured so completely differently from the other programs that specialist users in large companies and public authorities work with? And why do you need two different programs at all, if you want to quickly see the geo-context of a technical process?

Although it is absolutely obvious, there are hardly any development environments, frameworks and other tools to efficiently develop combined attribute data and geodata applications. This probably has historical reasons: In the beginning, GIS systems were mainly there for cartographers and other geodata specialists, and they essentially served only to develop thematic maps for different purposes. Since they developed completely separately from the rest of the PC and browser world, they function differently and are often difficult for occasional, inexperienced users to master. As a result, the GIS department in most companies and government agencies has become relatively independent from the rest of the corporate IT world – with completely separate tasks: One develops the software that business users use to process their processes and the other develops the associated maps. Until some time ago, this was normal, and no one bothered by this separation.

Changed expectations since Google Maps

However, since the advent of Google Maps and countless geodata-processing smartphone apps, the expectations of business users have changed fundamentally. Today, when you can see where the bus or the nearest taxi is, how to get somewhere fastest and what kind of hotels or restaurants are located nearby with just one click on your mobile phone, you ask yourself: Why is the high-end computer equipment in the office often not capable of displaying the facts you are working on on a normal street map, let alone selecting the objects you want to work on with the mouse on the map?

Apparently, only a few software manufacturers have come up with the simple idea of integrating sophisticated geodata representations (areas, lines, points) with all their subtleties, such as a legend and layers that can be switched on and off, directly into factual data-oriented applications. Customers have also rarely asked for this feature – simply because they have never seen it like this before and perhaps cannot even imagine it. We have been involved in numerous projects where customers, and not only end users, but even IT managers, had to be painstakingly convinced that it was possible. It was only when a runnable prototype of such a combined application was seen on the screen that the astonished exclamation came: “Oh! Now I understand. Yes, we want that!”

Embedded GIS as jointly developed plug-in standard

Why so many solution providers do not have something so obvious on their screens remains a mystery, but this will certainly change fundamentally, and very soon. But unfortunately it is not so easy to implement. For lack of suitable frameworks, developers have no choice but to integrate the ready-made map controls of existing GIS systems into their Java Script or Java or .NET code, and then to combine the functionality of both worlds as best they can. This poses a number of challenges, such as the need to ensure that the display of the objects you have just clicked on in both systems (the attribute data program and the GIS control) is always in synch with each other so that inconsistent data is not inadvertently displayed. It is even more difficult when it comes to inserting or deleting objects dynamically, because then you have to build a transaction across two separate worlds. At the time, a total of 20 docking points were identified that can be operated bidirectionally when embedding foreign map controls. Since the development effort for this very quickly reached a level that no single customer wanted to pay for, Scopeland Technology decided to work with a total of six GIS vendors and manufacturers to develop a common ‘Embedded GIS’ plug-in standard that could be integrated into or flanged to the respective points by the participating companies.

Solution providers become GIS producers themselves

This has enabled us to successfully implement many pilot projects in recent years – at any rate so successfully that customers were overjoyed to get a functioning combined application for material data and geodata at all. However, this was not satisfactory in every respect, because practically all GIS products integrated in this way had their own special characteristics, which meant that at least one of the 20 docking points was always supported, and often several were not supported. For example, it was not possible to control the conditional display of objects (e.g. red, green, and yellow houses) from within the application for attribute data in a market-leading GIS product. In another system, it was not possible to calculate distances, and performance was poor if you wanted to transfer a large amount of data from the attribute data application to GIS control for display, and a third system had completely incomprehensible error messages when the Internet connection was briefly interrupted.

Conclusion: The integration of normal GIS products into individually programmed specialist applications is possible, but never good enough for really demanding customers. In the end, a solution provider has no choice but to develop his own framework and thus become a GIS producer himself. Some software houses have gone this way, with varying degrees of success. At least this is a path that works, and it is quite common in some industries, e.g. energy suppliers and municipal companies. The few manufacturers who are fit to offer such solutions have thus carved out a fairly good market niche for themselves.

With low-code to Embedded GIS

While the embedded GIS approach for ‘normal’, hand-written application software can still be implemented with reasonable effort, especially if it allows to specialise in a certain industry and the features required there, all manufacturers of low-code development platforms are faced with a challenge: The low-code technology is based on the principle of ‘clicking together’ application solutions interactively and without programming from ready-made functionality in order to achieve brutal effects with regard to development costs and project duration, as well as the maintainability of the software. If one assumes that the demand for such combined applications will continue to increase, then the users of low-code products will expect that the currently active data objects can also be conjured onto a map with a single click, and of course with equally high demands regarding the other aspects and features of geoinformation systems.

Up to now, all the well-known manufacturers have had difficulties with this requirement. The embedded GIS approach actually does nothing else than to maintain its own GIS control and use its own geodata functions. But since everything has to work at the click of a mouse, and since it is impossible to know what it is going to be used for, it was necessary to develop a really complete, fully comprehensive GIS system, or rather: all tools of the platform had to be designed in such a way that they could process and display any information in an identical way, but in tabular form, as a chart or map control, or all at the same time. Thus, a fully developed embedded GIS concept does not simply embed an existing GIS component, but requires that absolutely everything is designed for both classical transaction processing and relational database work, and at the same time as a geodata system.

The effort of this fusion is considerable and it remains to be seen whether the demand will actually meet it. However, initial pilot projects at large federal authorities are proving that it works, not only technically, but above all in terms of user acceptance. The combination of factual and geodata processing in one application could thus prove to be a key feature for future development environments, especially for low-code development platforms.

Notes:

Further information on the subject of low-code can be found at https://www.scopeland.com/.

Karsten Noack has published more articles in the t2informatik Blog, including

t2informatik develops and modernises software as a service provider. Click here to learn more.