WFS Examples and Guidelines
Stored queries
If you want to know more about how to decide which storedquery_id to use, see Time series data page.
After you have decided which storedquery_id to use, you may request the actual observation or forecast data from the service.
For example, you may request forecast data for Helsinki with default values for other parameters:
Stored query parameters can be used to limit the queries, for example, to certain areas, locations, time period and features.
Simplified parameter list for stored queries:
bbox (for example: &bbox=22,64,24,68)
timestep (in minutes, for example: ×tep=40)
parameters (check possible parameters from server response by using stored query request without limitations, for example: parameters=temperature,windspeedms)
crs (check supported projections from getCapabilities-response, for example: &crs=EPSG::3067)
starttime (for example: &starttime=2013-02-26T20:00:00Z)
endtime (for example: &endtime=2013-02-28T20:00:00Z)
maxlocations (number of stations to search for in the vicinity of the requested locations)
place (multiple places can be defined by using parameter multiple times, for example: &place=kumpula,Helsinki&place=kirkkonummi)
List of all supported stored queries can be found from FMI WFS Services page.
Guidelines for stored queries
Timesteps should be adjusted according to requested time period and according to actual need for specific data. For example, short 10 minutes timestep may not be adequate for longer time periods and such queries may result in huge data sets. Therefore, longer timestep, for example 1 hour or 1 day, may be adequate for such cases. Data may be received much faster and more efficiently when only necessary data is queried.
Choose starttime and timestep properly or expected data values may not be received from the service. Proper observation and forecast data values are given only if data is available for queried time positions. The queried timesteps should be relative to an exact hour and also divisible by the actual observation interval. For example, if starttime _has been set for 2013-05-12T10:22:00Z with _timestep of 20 minutes and feature observation interval has been 10 minutes, no proper data values are received from the service because requested timesteps 11:22, 11:42, etc. do not match actual observation times that would be 11:20, 11:30, etc. Notice also, every second step of 15 minutes timestep would result unwanted time positions if the observation interval has been 10 minutes because 15 is not divisible by 10.
Note: You can avoid the matching problem described above if you set an exact hour to starttime (For example starttime=2013-05-12T10:00:00Z&).
Timevaluepair examples for stored queries
Lets examine stored query parameters from the result of following request
The result contains information about the request parameters supported with fmi::observations::weather::timevaluepair stored query. Every other stored query has its own set of request parameters. When one wants to use a stored query it is wise to check out what parameters it supports.
Lets try bbox, parameters and crs request parameters from the list.
The query uses bbox parameter that has multiple coordinates separated with commas as a value. The first two numbers express the lower left corner and the last two the top right corner coordinates of the bounding box. The value may also contain a projection information if the response is in a different projection than the coordinates of bbox. For example, bbox=22,64,24,68,EPSG:4326& could also be used above.
The crs request parameter in the query tell the target server which coordinate projection is required for the coordinates in the result. It also defines coordinate system of the bbox request parameter, if there is not another projection given in the bbox value. The possible values are given in the response of GetCapabilities request. Each feature type description has a list of crs values it supports. Because fmi::observations::weather::timevaluepair stored query is using PointTimeSeriesObservation feature type (the type is available in ListStoredQueries and DescribeStoredQueries response) the possible values for the crs parameter were EPSG::4258, EPSG::4326, EPSG::3035, EPSG::3067, EPSG::3047, EPSG::2393 and EPSG::3857 at that moment the tutorial was written.
The parameters request parameter selects temperature (t2m) and windspeed (ws_10min) data to the result. If the query was made without the parameter, the result would contain data from all default parameters available through the stored query, not just the two of them. If one wants to know which parameter values are possible to use with the request parameter, they are only seen from a query result of the stored query. In the result, each wfs:member element includes om:observedProperty element that has an attribute link for that purpose. The link itself or the data behind the link gives a description for the parameter.
Also, location names can be used with queries. For that purpose, the stored query supports the place request parameter. For example, query for all the timevaluepair data from the closest station to Jaala by using 30 minutes timestep:
Forecast query by using fmi::forecast::harmonie::surface::point::timevaluepair stored query works similarly with the above observation query. At first check available the request parameters for the stored query.
The result describes that there is supported the place request parameter. So, it is possible to make a point forecast query for Jaala.
Multipointcoverage examples for stored queries
Spatial query uses bbox parameter. Notice, the projection information may also be included in the bbox value if the response is a different projection than bbox values. For example, &bbox=22,64,24,68,epsg:4326 could also be used below. Query for combined list of positions and values for temperature and windspeed data in EPSG::3067 projection:
It is also possible to use location names in the query. For example, query for the closest station to Jaala by using 30 minutes timestep:
Query for point forecast for Jaala as list of positions and values:
Observation stations in the water temperature and wave buoy network
Lets find out what observation stations are in the water temperature and wave buoy network of the Finnish Meteorological Institute. Because the Web Feature Service (WFS) of the Institute uses stored queries extensively, we must solve which stored query returns Environmental Monitoring Network data. All available stored queries in the service can be fetched using ListStoredQueries request.
http://opendata.fmi.fi/wfs?service=WFS&version=2.0.0&request=ListStoredQueries&
In the result, there is a stored query that returns EnvironmentalMonitoringNetwork features. The stored query identifier is fmi::ef::networks. We can use the identifier on GetFeature request.
The GetFeature result includes multiple EnvironmentalMonitoringNetwork features. Examining the result, we notice there is a network for buoys (for example you can search "buoy" text from the document). The content of the buoy network description includes a link to the network facilities it contains.
http://opendata.fmi.fi/wfs/eng?request=getFeature&storedquery_id=fmi::ef::stations&networkid=137&
The result includes multiple EnvironmentalMonitoringFacility features. Each feature contains a buoy that is operational at the moment. We can also check operational buoys in the year 2010. To do so, we must check if there are time related request parameters supported.
The result says the stored query supports starttime and endtime request parameters. We can limit the time and get the operational stations in the year 2010.
Wave height on the Baltic Sea
As we learned from the previous example, operational buoys can be listed by using the following request.
http://opendata.fmi.fi/wfs/eng?request=getFeature&storedquery_id=fmi::ef::stations&networkid=137&
Every buoy has some spatial location expressed with coordinates. We can look at the coordinates and find the Pohjois-Itameri aaltopoiju (Northern Baltic Proper wavebuoy) station that is located in the Baltic Sea (latitude 59.250000 longitude 20.996830). Its numerical fmisid identifier is 134220. The identifier allow us to target a data query to that station, exactly.
Next we must find out a stored query that returns wave observations. From the result of ListStoredQueries request we find fmi::observations::wave::timevaluepair stored query which title says "Wave and Water temperature observations". Then we can make GetFeature request with the storedquery identifier (storedquery_id=fmi::observations::wave::timevaluepair&) and the station identifier (fmisid=134220&).
The result contains data from multiple measurands (if the sea is not freezed). Each wfs:member in the result contains data from one measurand. Behind the attribute link of om:observedProperty element is described which wfs:member contains data from the wave height measurand. The measurand parameter name is WaveHs.
It is also possible to fetch wave height forecast data for the location of buoy. The coordinates are already known from the result of fmi::ef::stations stored query. The result of ListStoredQueries request gives us fmi::forecast::wam::point::timevaluepair identifier. Its title is "WAM Wave Model Point". The message is not the most descriptive but it does return forecast data for the Baltic Sea. We can check the details using DescribeStoredQueries request.
Combining the stored query identifier (storedquery_id=fmi::forecast::wam::point::timevaluepair&) and the coordinates (latlon=59.250000,20.996830&) of buoy to GetFeature request, we get wave height forecast to the location of buoy.
Every wfs:member in the result also contains om:observedProperty element with a link to the description of forecast parameter as was in the result of observation query. The forecast parameter of wave height is SigWaveHeight.
We can go further with this usage example and combine the wave height observations and the forecast data to continuous time series from the past to the future. It requires use of starttime, endtime and timestep request parameters. It is possible that wave height observations do not come available instantly, which creates an empty gap between observations and the forecast. For getting forecast data from the past, it requires the use of time related request parameters. Also, the observations are returned in every 30 minutes and forecast in an hour period which requires use of timestep request parameter. I'll leave this task to you. Would you like to try?