Our monitoring network experienced a service interruption on Apr 23rd 2015 from 9:20 to 10:40 UTC. No monitoring data was collected during this time. During this interruption Spatineo Monitor and Spatineo Performance were accessible and usable, but users were unable to configure services or meters and it was not possible to add new services for monitoring. This interruption was caused by malfunction in crucial services provided to us by Amazon Web Services. We noticed this malfunction right as it begun and reacted to the developing situation as quickly as possible. Monitoring was resumed immediately after the services were fixed.
Monitoring is now operating nominally and we are keeping a close eye on the situation. We apologize for any inconvenience caused by this interruption.
Spatineo monitors a large amount of web services, and most of these services are publicly available over the internet. Monitoring works in a completely automated fashion in typical cases. In some cases though, our customers are interested in identifying which requests originate from our monitoring. For example some services may require authorization using HTTP authentication, User-Agent filtering or IP address white lists.
HTTP Basic Authentication is widely used in OGC as well as with other web service protocols. As the name says, it is very basic and it is not ideal or the most secure authentication method available, but it is supported by almost all HTTP clients and servers and, despite the valid criticism, it still has its uses. If you combine Basic Authentication with a properly secured HTTPS transport, it is still a relatively good authentication method. Even without HTTPS, it does give the service provider more control over their service for example, to block offenders if irregularities arise.
Users of Spatineo Monitor may set up the basic authentication parameters used when we send requests to their service via service parameter configuration. These parameters are used for retrieving service descriptions, monitoring requests and performance tests.
In addition to HTTP Basic Authentication, our customers can configure extra query parameters or HTTP request headers that will be sent on every request.
All monitoring requests use the HTTP User-Agent request header to tell the server that the request is coming from Spatineo. This is the most precise way of knowing which requests are sent by us. For monitoring requests, the User Agent also contains a link to the Spatineo Directory page of the monitored service. Please keep in mind however that the User-Agent identifiers we use are well known and as such, are unreliable for authentication.
The User-Agent for querying for new services or updating previously known services is:
User-Agent information is also helpful if you wish to allow or block monitoring from us by using the robots.txt mechanism.
The Spatineo monitoring network is comprised of multiple servers running in multiple data centers. Monitoring requests, performance tests and service discovery all come from different IP addresses. We keep an up to date list of the IP addresses used by monitoring and service discovery which is available at http://directory.spatineo.com/public/monitoring-ip-list.txt. The list is automatically updated when IP addresses are added or removed from the list.
Please keep in mind that this list does not include the IP addresses that Spatineo Performance tests originate from.
Our CTO Ilkka Rinne was selected as the facilitator of the workshop on INSPIRE validation and conformity held in Ispra, Italy in early December 2014. In this post he describes some of the issues they were (and still are) working with, how he sees the future of the INSPIRE conformance testing based on Open Source code and community involvement.
A misty view from the Hotel Lido in Angera over the Lago Maggiore. At this time of year the breakfast was the time to take photos, after the workshop day it was already too dark.
INSPIRE conformance, what does that mean exactly?
EU INSPIRE directive is at the centre the multi-national activity for building a Europe-wide Spatial Data Infrastructure (SDI): a network of online Spatial Web Services providing spatial data collected by public authorities in all EU member states. The aim is to be able to find and fetch data from mineral resources to up-to-date weather conditions, and administrative borders to animal species distribution on-demand from directly from the authorities collecting them.
The INSPIRE directive mandates the public authorities to publish their data sets in harmonised formats using standard web services. The data users including other public authorities, research institutes, private companies and citizens are able to use same software products for viewing and downloading the INSPIRE data sets from any member state. According the INSPIRE vision it should be easy to compare these data sets and use them as up-to-date input data for all kinds of applications and decision making processes.
The seamless INSPIRE data-sharing vision does not turn into reality without formal regulation and technical guidance on the data content, metadata, formats and service interfaces to use within the technical INSPIRE infrastructure. Fortunately there are already good general data and service standards in the field of Spatial Data that can be adopted for the INSPIRE use provided by well-known standardisation organisations like ISO and the OGC. These standards provide a solid base for technical interoperability on which the INSPIRE SDI can be built on.
The INSPIRE specific requirements for datasets and services, as well as the metadata records describing them, are given in INSPIRE Implementing Rules (IR) and their corresponding Technical Guidance documents (TG). The IRs are published as part of the EU legal regulation (directives), to be implemented as national laws in the EU member states. The TGs are not legal text, but provide a help and working examples for technical solutions the member states can use to abide to the IR legal requirements.
An EU member state may conform to the INSPIRE regulation using one of the options outlined by the Technical Guidance documents or in any other means, provided that it can show that this alternative method still fulfils the IR legal requirements. The later approach is generally not recommended because it’s likely to cause technical interoperability problems between the data exchange between the member states. However, it would also be problematic to bind a particular technical solution to the inevitably slow process of the EU-wide legal regulation system: It’s a lot simpler to keep a technical document up-to-date if every change does not have to be ratified in the parliaments of 28 countries.
The downside of having two levels of requirements is that the term “INSPIRE conformance” is bit tricky to define: Does that mean that the IR (legal) rules are fulfilled? Or that the requirements in a particular Technical Guidance are fulfilled? These questions and harmonising the results existing INSPIRE validator software solutions used in different member states are in core focus of the INSPIRE Maintenance and Implementation Group (MIG) activity MIWP-5: Validation and conformity testing.
A workshop with a clear focus
One part of the MIWP-5 activities is analysing the requirements written down in the current TG documents and trying to formalise tests for validating services, datasets and metadata records against these requirements. I’m the facilitator of the small and active group of people currently working with this subtask. Last week on 2nd and 3rd December 2014 we had a two-day workshop on this matter kindly hosted by the JRC Institute for Environment and Sustainability which is part of the European Commission’s research facilities in Ispra, Italy.
From the total of 208 requirements in the Technical Guidance documents for INSPIRE Metadata, View and Download Services we chose to focus on the ones considering metadata, view service implemented using the OGC Web Map Service and the file-based download service option implemented using Atom feeds. Even with this limited focus we had almost 160 requirements on our plates – more than enough for two workshop days.
The main task as to define Abstract Test Suites (ATS) for each of the implementation options. These sets of natural language test case descriptions will then act as functional requirements for validation testing programs, or Executable Test Suites (ETS), which form the core of the validator software implementations for INSPIRE conformance testing. The Technical Guidance documents also contain a number of requirements for which it is very difficult, if not impossible to formulate a mechanical pass/fail test: Sometimes it takes a human expert or external knowledge to assert if the requirements are fulfilled or not. This is completely ok, but for making automatic validation tools it’s important to separate the two. Passing a mechanical validator can never guarantee a 100% conformance, but a good validator can help the work considerably by helping in spotting many common errors.
Schematic on relations of INSPIRE IR and TG requirements and the Abstract and Executable tests. “CC” stands for conformance class.
I’m glad to say that we made good progress with the work in these two days: We agreed on the format for the Abstract Tests, had very good discussions around the challenges in some of the TG requirements and the ways to work around them, and decided on the next steps and dead-lines for finishing the work.
Increased transparency with Open Source validation code
Validation rules and techniques used for evaluating the official INSPIRE conformance must the be transparent. If a validation fails for some input it must be possible to check how the validator code has been implemented. As in any software product there will be bugs and certain inputs that will result on false validation statements. In order to spot these weaknesses and make the validation code better in time, we strongly support the idea of publishing both the Abstract Test Suites and at least the officially endorsed validator implementations as Open Source projects.
I believe that the fact that code and it’s functional requirements are openly available and easily extendable, is a key to the INSPIRE conformance testing success. Only by being open and getting the developer community involved in the process can we get keep the testing codebase continuously up-to-date. By carefully choosing the licenses used we can create living and continuously improving shared validation codebase and still make it feasible for companies like us at Spatineo to create additional value for our users by focusing on thing like usability and integration with our other products.
As any successful Open Source project the INSPIRE validation projects also need clear governance and change management processes. It must be clear which versions, forks and branches are officially endorsed by the project leads. For INSPIRE the obvious authority for approving the ATS and validator library code changes would be the MIG. In practise the work of filtering and consolidating the code change proposals, preparing the changes for MIG approval, and creating the official releases would have to be done by some kind of expert board, the members preferably chosen amongst the top contributors but also having some technically oriented MIG representatives to guide the direction of the work.
As one result of the workshop we have now have set up public ATS repositories at Github under organisation inspire-eu-validation. While writing this the ATS drafting is still in it’s early stages, but the content will add up as we approach the February 2015 dead-line. The ATS texts are published in Public Domain using Creative Commons CC0 1.0 Universal license. The license used for the executable validation code has not yet been decided, but I’m pretty confident that it will allow the code to be used as a software library in both open source and closed source applications.
Spatineo will be contributing both design time and our expertise in the INSPIRE & OGC validation to these ATS and ETS projects. You may ask what is Spatineo getting out of participating in this work? The answer is that with Open Sourcing of the validation logic we can focus our development resources for keeping the usability of INSPIRE validation tools top-notch while still ensuring that we can always provide the officially endorsed validation results to our customers. Making Spatial Data Infrastructures “tick” is what we do at Spatineo. Being able to build more reliable tools for validation is an important part of that work.