Working (and blogging) at Cafe Piritta today for a change. Very good lunch, a bit pricey though. I’m about to leave for Vienna today to meet with the INSPIRE Thematic Working Group for atmospheric and meteorological data ( Atmospheric Conditions & Meteorological Geographical Features themes, TWG AC-MF in the INSPIRE jargon). I’m privileged to be a member in the group on half of our customer the Finnish Meteorological Institute.
Interesting two days to go through the comments on the Data Specification version 2.0 of our theme, and to figure out how to proceed with the final version of the spec. We’ve received a bunch of comments, which is good, because it means that the EU member states are interested in what the INSPIRE requirements for the meteorological and atmospheric data are going to be like. The task we’re facing is challenging, because the expectations span both data policy (what data to include) and the technology (how to share that data in interoperable, INSPIRE compatible way). I just wish we could focus just on technology, because that alone is enough to occupy our minds for some time.
My personal goal for the Data Specification would be to make it an instantly usable guideline on how to implement an INSPIRE compliant OGC Web Service interfaces intended for the tech-savy people working for the different institutions dealing with meteorological data.The current version of the specification is not straightforward enough. If I want to publish an INSPIRE compatible Download Service for delivering meteorological observation data from ground observation stations, what service do I use? The answer is probably an OGC Web Feature Service 2.0 with INSPIRE additions, but this is not explicit in the spec. The data model for the met data is specified, but how it should be mapped to the View Services (Web Map Service) and Download Services (WFS, possibly Web Coverage Service or Sensor Observation Service) is not very clear.
There are separate guideline documents for implementing INSPIRE Discovery Services, View Services and Download Services, but they may not be a perfect fit for the themes involved with measurement data, like our AC-MF or the Oceanographic Geographic Features. Our data model is based on a general ISO/OGC Observations & Measurements (O&M) model, which is a good, solid framework to build on, but it also means the you can extract only very little information about the actual measurement data from the model itself. Thus the model does not really tell you what data is expected, unlike in the themes like Transport Networks, where the kinds of roads, crossings etc have different classes in the model. We only have “Observation” instances, which could as well contain data originated from ground observations, weather radar or numerical forecast models, and thus need to be more specific about the expected data types and suitable service interfaces than most other themes.
Well, a challenge it may be, but pursue it we must nevertheless. I must say it’s a relief to be aquatinted with some hard-core experts in the area of O&M to ask for advice. Like in most contexts, it’s nice to know you’re not alone :-)
