Since VIPS consists of multiple subsystems, this project is a starting point for VIPS documentation, describing the system as a whole. Documentation to each subsystem is linked from here.
Since VIPS consists of multiple subsystems, this project is a starting point for VIPS documentation, describing the system as a whole. Documentation to each subsystem is linked from here.
## Further reading
*[VIPS Weather data specification](./weather_data.md)
# Specification of external weather data source for VIPS
## Preface
This is a description of how a weather data provider can make weather data available for forecasting models running in VIPS, NIBIO's system for forecasting agricultural pests and diseases.
## General description
* Weather data should be available over the HTTP protocol
* The service should be able to provide a requested set of parameters in a requested time period.
* Input parameters to the service are given as request parameters in either GET or POST format.
* The data should be presented in Json format (http://www.json.org/).
* We do not distinguish between measured data and forecast data. They are presented seamlessly as continuous time series.
* The common way to establish this service is to have a web server in front of a database with weather data.
* The square brackets signal the start (`[`) and end (`]`) of a list of weather data
* The curly brackets signal the start (`{`) and end (`}`) of one weather observation (or forecast)
* Comma separates each weather observation. No comma after the last weather observation.
* Each observation (or forecast) has a time stamp (`timeMeasured`) in the ISO-8601 format (http://en.wikipedia.org/wiki/ISO_8601), which always includes time zone.
* Each value has a parameter code (`elementMeasurementTypeId`) that describes what kind of measurement (or, indeed, forecast) this is, and implicitly also the measurement unit. Se appendix A for a table of parameter codes and their description.
* Each value has a `logIntervalId`, which describes the aggregation or frequency of the measurement. A value of `1` = hourly measuring frequency. See appendix B for a table of logintervalIds.
## Input parameters
|Parameter name |Description |Format |Example |
|-------------- |----------- |------ |------- |
|startDate |Date for first observation in series |ISO-8601 date |2013-08-01 |
|startTime |Hour of day for first observation in series |Zero padded integer |01 |
|endDate |Date for last observation in series |ISO-8601 date |2013-08-15 |
|endTime |Hour of day for last observation in series |Zero padded integer |23 |
|timeZone |Timezone for input data and output data (timeMeasured) |IANA TimeZone database ( http://en.wikipedia.org/wiki/Tz_database ) |Europe/Oslo |
|logIntervalId |aggregation or frequency of the measurement |Number |See appendix B |
|elementMeasurementTypes |The requested weather parameters |Array of strings |elementMeasurementTypes[]=TM |
## URL pattern for external weather data source
All weather stations (or measuring points) in the same external weather data source must have a uniform URL pattern. E.g.:
The `[weatherStationId]` is a placeholder for the unique identificator for a particular weather station. It need not be numerical (although that is recommended), but it must be able to easily pass on as part of a URL.
## Quality of service
* VIPS expects the series of weather data to be complete, meaning that there are no holes (missing values for one hour, for instance) in it. Some interpolation might be attempted on the receiving end (VIPS), but it's the weather service's responsibility to ensure a complete data set.
* The time series may not contain duplicates, meaning two entries with the same combination of
* timestamp
* parameter type
* log interval
* In the case of missing data (which ideally should not happen), a value/object should not be output for the missing parameter/timestamp/station. If the service contains no data for the given station/parameters/period, an empty array should be output: «[]». A server error status (500) with an error message should be returned unless the GET/POST parameter ignoreErrors=true is set.
## Appendix A: Element measurement types (excerpt)
Due to a wish to standardize the names of the codes using international standards, the names of the codes may change in the future. Its definitions will stay the same.
|Swedish University of Agricultural Sciences|http://www.ffe.slu.se/lm/json/downloadJS.cfm?weatherStationID=[weatherStationId]|[LantMet](mailto:lantmet@slu.se)|
