Get Smart with Widgets – How to be transparent with your spatial web services?

Get Smart With Widgets

As more and more spatial web services and more and more data, are being opened to the public, it becomes vital to display more and more of transparency. How are your services working, and how is that information shared with your users? We have figured one very efficient way to relay that information for everyone to see!

Users and your IT can reach information easily

“I’m having trouble, I’m wondering if the service is working properly at the moment?”, “Is this service reliable enough to use in our application?”, “Is there any planned maintenance in the service I should be aware of?”

These can be questions your users and even your own employees might be wondering from time to time. These can be difficult to answer, and even with experienced IT personnel it can take quite a while to answer these relatively simple questions your users have. What if this information would be automatically and transparently available to everyone?

We think this kind of transparency of quality in spatial web service is vital. Your services might be used by for example first aid personnel who need that data to be reliably accessible. Achieving this kind of credibility is something you need to build slowly and maintain. Giving information about the quality of your services is one key factor when building this trust.

This is where the widgets in Spatineo Monitor can be an amazing solution for you.

Dashboard of your spatial web services

We are just going to jump to the awesome results we have witnessed our customers have been able to do. Informatie Vlaanderen from Belgium is one of our customers, who have taken the mission of transparency very seriously. They are really ahead of the game with this one. Their spatial web service dashboard ( is a prime example where the organisation displays openly the status of their services. The page shows the current status as well as historical availability and the information is there for everyone to see. Anyone can find this page and see themselves that Informatie Vlaanderen’s services are top notch. 

We have also noticed that the “dashboard format” is quite ideal for these widgets. The layout Informatie Vlandeeren made displays all services in a neat and compact format. You can check the availability and notifications of any service in mere seconds from single page. 

One of the reasons why widgets in Spatineo Monitor can be trusted is that the monitoring is performed by a third party. Spatineo tests the services by accessing the services exactly how users would access them. Therefore our monitoring gives very accurate information on how reliable those services are.

So, how to get smart with Widgets?

Displaying availability widgets is actually a really simple process with our tools. We’re not even exaggerating when we’re saying that the whole process can be done in few clicks. 

Log into Spatineo Monitor, select which service you want to show, go to the sharing tab and copy the “widget loader snippet”. See the animation below for how to do it.

Geospatial Availability Widgets

So now that you have the snipped copied, all you need to do is paste that into your webpage. The animation below you can see how easy it is to add the widget to a WordPress site.

Vóila, you can see the result below. This widget shows the availability of the Finnish Environment Institute’s INSPIRE Hydrography web map service.

The examples our customers have created for themselves are a little bit more complex, but anyone with basic HTML skills should be able to pull of similar layouts. Your imagination is the limit! 

We would love to see your availability widgets in action! If you have implemented our solution, please share that with everyone – Examples help everyone else to achieve better transparency and assist their goals to help their own users.

Want to stay ahead of the game, and get latest news from us? Subscribe now to our newsletter!

The economic benefits of geodata in digital urban planning and building process

Spatineo Inc. and its partner GIS-kvalitet i Norden supported Lantmäteriet, the National Land Survey of Sweden, in answering an essential and important question “What is the economic benefit of national harmonization and standardization of geodata and the national platform for access of geodata?”. The companies made together a project to Lantmäteriet  in which they assessed the potential economic benefit of the use of geodata in the digital urban planning and building process in Sweden. The estimated annual economic value is 22,6 – 42,2 billion Swedish crowns.

Goal of the study

The urban planning and building sector is the biggest sector in Sweden that effects on the built environment. Therefore, Lantmäteriet has been commissioned by the Government to work for a streamlined digital urban planning process. The goal is a more effective interaction between authorities, citizens and businesses. This is promoted by providing all actors the most important national basic datasets as a geospatial service from the national platform. National basic datasets are mainly produced by cities and municipalities.

It was already stated by Smart Built Environment in 2016 that an “unbroken” information flow in urban planning and building process can save billions of  crowns. The main goal of our study was to analyse in more detail the economic benefits of the subprocesses and show the estimated total value.


Our study is a meta-analysis of both Swedish and international studies in which the economic impacts of the use of geodata have been analysed. Results from international studies has been applied to Swedish conditions so that national statistics related to number of units and users, revenues, salaries etc. have been used. One core requirement for the existing studies that has been utilized in this study is that geodata has been an essential part of application, service or product that produces the benefits to users. Without geodata the economic benefits would not have been realised.

Economic benefits

The urban planning and building process includes the following subprocesses: general planning, detailed planning, real estate formation, building permit, building and construction planning, groundworks and construction, and maintenance. Our analysis shows that the biggest economic benefit can be gained in the groundworks and construction, in total 19,4-38,8 billion Swedish crowns. The second biggest economic benefits can be gained in building and construction planning, 3 billion Swedish crowns.

The economic potential of geodata in digital urban planning and building process

Open geodata

In our analysis of the potential economic benefits we have not taken into account whether the geodata is open or not. However, it is emphasized in the report  “Nationella basdata från stat och kommun” by Geodatarådet in 2017 that fully financed open geodata from a national service is making the digitalization of public processes much easier and faster, and stimulates innovation and growth of small and medium size private companies.

Lantmäteriets report “Nationellt tillgängliggörande av geodata i samhällsbyggnadsprocessen” is based on Spatineo’s and GIS-kvalitet’s report “Ekonomisk nytta av geodata i samhällsbyggnadsprocessen i Sverige”. You can download the full study for free here.

Spatineo Inc. ( is specialised in providing SaaS and professional services in the field of quality assurance for spatial web services, Spatial Data Infrastructures and impact assessment.

GIS-kvalitet i Norden AB ( is owned and operated by Helena Ringmar, the GIS strategist and certified business architect with over 30 years of experience in running projects and get the benefit of geographical information to businesses.

WFS3 is a novel OGC API for feature access

When browsing through the OGC Web Feature Service (WFS) version 2.0 standard the first time back in 2011 I remember wondering how close the API it defined was to a generic database access: all the basic CRUD (create, read, update, delete) operations, data query with filtering, and no fixed definition for the data model of the information the service provides. In a way it seemed like a neat generic solution to publishing various kinds of spatial “feature” data using a single set of defined operations, but on the other hand building a client application to work with such a generic API seemed, and still is, a challenge.

In a way the API in WFS standard was only defined half way: there had to be a predefined agreement, in addition to agreeing on using WFS, between the client and the service on the data content and structure for interoperable data exchange. Gradually I’ve also started to wonder what all this technical agreeing and coding has to do with handling geospatial data, and shouldn’t we use the same solutions for defining interoperable APIs as everyone else in the Web world is using, and as it turns out, I’m certainly not alone thinking along these lines.

The idea of using mainstream API technologies, resource-oriented data access patterns for spatial data and generally making the browsing the data both more web-browser and web-developer friendly has been pioneered in the development of the OGC WFS 3.0 standard now officially called “OGC API – Features: Part 1 – Core”. This new standard has been written entirely from scratch, and it’s really a completely different beast compared to its predecessor WFS 2.0: It embraces (although does not mandate) defining the service API using OpenAPI specification (previously known as Swagger) with wide industry and tool support outside the geospatial domain. It also introduces JavaScript Object Notation (JSON) format as a first class citizen for both the service and the data encoding, although XML encoding is still a viable option.

In addition to making adopting a spatial data API more straightforward to developers, the OGC API – Features standard also encourages server software implementers to make the services speak the native language of the Web: HTML service landing page as well as web browser accessible feature collection metadata and data content browsing rises the accessibility of a service on the completely new level compared to having the traditional OGC Web Service capabilities XML document.

HTML representation of features in available in WFS3 collection “opendata_1h”

The OGC WFS/FES working group responsible for defining the new OGC API – Features: Part 1 – Core standard is currently working with the first release candidate version of the specification to be submitted into the official OGC and ISO / TC 211 approval process. The core standard in intentionally stripped down what comes to functionality: even the pretty common place functionality such as support for coordinate reference systems additional to WGS84, query filtering beyond bounding box, time, and explicit feature property value matching, and updating feature collections, will be defined as extensions to the core standard. This allows implementing only the subset of the functionality really required for particular use cases and environments. Considering fact that this new standard is a galaxy away from being backwards-compatible with WFS 2.0, and the considerable existing investment made in the WFS 2.0 technology, it’s clear that both standards will be actively used for quite a while.

The working method for getting up to this point has been open and transparent with the first draft version made publicly available in April 2018. The ideas and the requirements have been properly wetted in hackathons, various software implementation projects and using the project’s open Github repository. The group members have strongly expressed that the final standard should be a technically mature, stable basis for building feature based spatial data web access APIs. No wonder there has been considerable interest within the OGC membership to follow the path set by the WFS/FES standards working group and widening the scope of the new kind of spatial data APIs outside feature data.

Timeline for the standardisation of OGC API – Features: Part 1 – Core

We at Spatineo have had the opportunity to be one of the early implementers of the OGC APIs – Features / WFS3 specification as we have worked together with the Vaisala and the Finnish Meteorological Institute technical people in the Simple Observation Features Pilot project (SOFP). The idea has been to create a proof-of-concept for testing out two sides of the same coin:

  • How well does the well OGC API – Features specification fit for delivering dynamic data such as near real-time weather and air quality observation data?
  • How the draft Simple Feature profile for Observations and measurements (OMSF) data model with JSON and XML encodings really work with real-world environmental observation and forecast data?
  • How well does the combination of WFS3 API and OMSF GeoJSON encoding work with existing GIS and web map applications with as QGIS, OpenLayers, Leaflet?

OMSF GeoJSON features extracted from the FMI SOFP WFS3 service presented in web application (

The project started in August 2018 and it’s expected to end in October 2019. The front-end server component developed during the project (sofp-core server) is based on Node.js server engine and delegates the data requests to one of the configured backend modules. A few notable links on the project for those interested in more details:

The SOFP project will culminate in the Inspire Helsinki 2019 Data Challenge in September – October 2019 where the SOFP APIs and various data sets are being used by voluntary coding teams in a hackathon-like fashion to create novel apps and ideas for improving the urban commuting by cycling, walking etc. in varying weather, air quality and other environmental conditions. The registration for the Data Challenge will open in early June, so stay tuned!