Interpolation web service requirements

From Intamap

This page gives the functional and non-functional requirements for the interpolation web service as a simple list of what the system should be able to do! Note this is not about the interpolation algorithms, whose requirements as specified elsewhere.

See also Web client requirements and Interpolation algorithm requirements.

Some terms:

• SOS: Sensor Observation Service - used to store observations.
• swe common: Sensor Web Enablement common XML schema - the base schema used in O&M and SensorML.
• O&M: Observations and Measurements schema that is used in SOS to store the result (observation) from a sensor.
• state: the variable that the user is interested in plotting (note this is not always the same as the observations).
• observation: the measurement obtained by a sensor, often in raw units of the measuring device.
• observation operator, forward model: the function that maps the state into the observations.
• interpolation server: the implementation of the web service to support automatic interpolation, probably as a web processing service.
• user: any user of the system, human (interpolation expert or application based), web client, or other web service.

Contents 1 Functional requirements - things it can do 1.1 Outputs 1.2 Inputs 1.3 Additional specifications 2 Open questions 3 Non-functional requirements - things it should be 4 Comments

Functional requirements - things it can do

To try to simplify things I have used colours to indicate what might be in which version:

• Version 1: the most basic version, ready for 3-4 April 2008 INTAMAP meeting.
• Version 2: the next version ready for end of year 2.
• Version 3: the final version ready for the final INTAMAP meeting.

Outputs

• Output will be univariate in nature; once this is solved we might attempt multivariate outputs.
• Output will include an estimate of uncertainty, by default the mean and prediction variance.
• Return the result as a coverage (grid - the default, can be defined in the request, but a default will be assumed otherwise) or over a set of points or averages over polygons or lines defined by the user in the request.
  • Allow a grid to be defined by an origin and non-equal spacing (regular grid; origin, offset format) or a bounding extent and number of points at which the grid is defined (irregular grid).
  • All other requests for interpolation over non-grids must compute a set of points inside R, as a preprocessing step and aggregate these as a post-processing step.
• INTAMAP will provide a map server (probably KYX generic client) that will provide a simple map for non-expert users.

Inputs

• We will start with a single (univariate input), without any explanatory factors (also called external factors) although we might investigate these later in the project if resources permit.
• Accept a series of observations from a SOS in an accepted format, and automatically interpolate these, given an instruction sent by a user.
• Accept a series of observations sent by the 'user' in an accepted format and automatically interpolate these.
• Allow the user to specify what is desired to be returned as a summary of the predictive (posterior) distribution:
  • The mean or mode or median
  • The marginal mean and variance (std) or specified confidence intervals
  • Moments of the distribution
  • The distribution itself (as a pdf, mixture model, histogram, quantiles, samples from the posterior)
  • A realisation of the posterior process
  • The probability of exceeding a critical threshold defined by the user.
• Allow the user to optionally specify information to be used in the interpolation process including:
  • allow the error characteristics of the observations to be described in UncertML - this needs to be parsed and evaluated
  • allow the sensor model to be described in sweCommmon - this needs to be parsed and evaluated
  • allow the user to specify the support of the observation - we need to define this and parse this
  • The interpolation process to be used (e.g. Universal Kriging, Projected Process Kriging, Bayesian Kriging, Spartan Kriging).
  • Determine whether harmonisation is to be applied, default is yes.
  • Set values of parameters in the interpolation process where this makes sense (this implies a schema to describe the interpolation processes in some detail!).
  • Define prior distributions over parameters in the interpolation process where this makes sense (this implies a schema to describe the interpolation processes in some detail!).

Additional specifications

Accepted format might mean:

• GML observations?
• swe common?
• O&M?
• INTAMAP extensions to swe common?
• All formats should be able to sent / received compressed.
• ?Other standard formats? e.g. lat, lon, value as a csv file? Binary?

Open questions

• How do we return information (meta-data) about the interpolation process? E.g. variogram parameters, clustering used? ....
  • This will require a complete schema to describe the interpolation process. AST is happy to create a schema for our methods, but we cannot foresee creating schema for all other methods - people will have to take some responsibility for their own algorithms (we can help!).
  • This schema would in any case be needed to define the interpolation method in detail if users need this - we feel we should provide this but I am not clear whether this was agreed at the meeting.
• For some methods (especially PPK) the most efficient return type would be the parameters on the active set, which could then be converted client side to the predicted values?
• The client (validation) will be used to automate the choice of interpolation algorithm, if we pursue this?

Non-functional requirements - things it should be

• reliability: ?the system should report load if this is likely to cause delay and should report on progress for large jobs? It should always return helpful exceptions?
• usability:
• performance: the service will be almost instantaneous in response (?latency < 2 seconds?) and will report status in a timely manner.
• portability: the system should attempt to be portable however this is not a major issue since the web service nature means it can sit on pretty much any architecture (AST plan is Linux, Java, Apache)
• extensibility: the system should readily accept new interpolation methods, and a range of sizes of observation sets (?2 - 100,000?)

Comments

Back to System Requirements.