Augmented Reality Wind

Visualising the current, past or future wind at (around) a location

User Story

The idea is to use augmented reality, presented on a mobile phone, tablet or even head-up display, to show the surrounding wind. The wind speed and direction is forecast on a regular horizontal 1Km grid, for up to 36 hours in advance. Wind data is also available for the last 48 hours.

The wind is visualised with wind arrows that scaled according to speed, and also striped for every 5 knots of wind speed, to improve the perception in a perspective view where some wind arrows may be several kilometers distant.

The wind data is pre-formatted into, for example, 10x10km squares, each containing 100 values, and by default, the 9 'data tiles' surrounding the location of interest, for the current time, are loaded. Extra tiles from further away or different times can be loaded as requested. A manual control allow the user to scroll backwards or forwards in time.

Similarly, if wind data for higher levels in the atmosphere, such a 100m, 200m, 1Km etc, are of interest, they can be requested and the user manually 'scrolls' to a different altitude. The user may be a balloon pilot, hang-glider or tower crane driver. [This was not implemented in the proof of concept project, though the data was available.] It is envisaged that such data may be all downloaded in single 'thick' tiles, or data cubes, to reduce latency and overheads. This is envisaged as a separate service, optimised for a particular user group.

The wind arrow, with attributes of colours, size and direction, was in a standard 3D object format and could have been displayed as, for example, an aviation wind sock or weather vane, to suit a particular user community or even user preference. Each arrow was displayed on a 'pole' to accurately locate it on an underlying 2D surface map, which could be 'seen' by looking vertically downwards and 'zooming out'. The street names were always seemed to upside down though, just as one's location is always at the corner of a a map tile!

Data at 1Km resolution makes a convincing augmentation of reality, in that several dozen surrounding wind arrows can be seen in the vicinity, revealing the changes in direction and speed.

The meteorological authority issuing the wind data does not allow interpolation, or filtering, of the data to different resolution grids, as this can be misleading and dangerous. No meteorological service is capable of forecasting for the complete globe at 1Km resolution for the next decade or so, so data at this resolution has to be supplied by local service providers, such as the National Meteorological Service of the location of interest to the user. Typically, global data is only available at 15Km or coarser resolution for the next decade or so. At this resolution, the augmented reality experience is not convincing: "I know there is a wind datapoint around here somewhwere, if I can find it".

Coarser, global or continental, data may be of use in some applications, such as international aviation.

The data was made available through a cloud server. A large grid of nearly 1000x1000 points was uploaded, in either NetCDF or similar format, and then decomposed into fixed tiles by python scripts. Scripts also kept track of the rolling buffer of current data, garbage collection of expired data, etc.

The API keeps track of cacheing and which users have requested which data tiles.

Background

The WindAR project was initiated in October 2012 by the project partners (UK Met Office, Perey Research & Consulting, Augmented Technologies Ltd and DeTron) to investigate the feasibility, from both a business and technical perspective, of visualising large scale meteorological information on mobile devices, such as smartphones and tablets.

A reference implementation was developed, covering both client and service elements. Business and case study initial findings were presented to the OGC, Augmented Reality (AR) and meteorological communities, covering:

• The experimental Met Office streaming data service;

• The consumption of this data within a mobile (smartphone) application;

• The limitations of the current implementation;

• An investigation into alternate service and data formats to provide the ‘ground-work’ for any future stages of the project.

Actors

  1. Server supplying data tiles covering Area Of Interest/service.
  2. One client, of many, receiving data tiles local to clients' Points Of Interest.
  3. Intermediate web caches to allow other clients to receive the same tiles if of interest.

Preconditions

The server and client have negotiated a tile service for an Area, vertical extent, time or other dimension, Of Interest.

Main Success Scenario

As client's Point of Interest moves in space and time, the client's local copies of data tiles are replaced and unneeded data tiles are deleted. The data tiles received allow the client to make informed decisions and alter behaviour, either by calculation or visualisation.

Alternative Paths

  1. Client moves out of range, or out of time, of service and must negotiate a new service with another supplier for new Area Of Interest.
  2. The offered service does not have data of the appropriate (high enough) resolution to make informed decisions or sensible calculations or visualisations.

Postconditions

The recently used/requested tiles remain in the local client storage, unless time expired.

The recently used/requested tiles remain in the web cache, unless time expired or the service enforces no cacheing.

Requirements Issues/Discussion

  1. Each tile could have a time extent with several data times, or each tile could have data only for one instant and separate tiles must be requested to cover a time period.
  2. Each tile could have a vertical extent with several data altitudes/levels, or each tile could have data only for one level and separate tiles must be requested to cover a vertical extent.
  3. Each tile could have a different, dimensional, extent with several data dimension values, or each tile could have data only for one dimension value and separate tiles must be requested to cover that dimensional extent. E.g. wavelength of imaging data.
  4. It is envisaged that tiling is primarily horizontal (x,y) in extent, with z and t coordinates 'added'. It is possible that the primary tiling could be in, say (z,t) space.
  5. Each tile could contain several different parameters of interest, or each tile could have data only for one parameter and separate tiles must be requested to cover that dimensional extent. E.g. Vector or tensor valued parameters, such as wind components or current speed and direction should probably be in the same tile, so a 'scanning pattern' is needed.

-- Main.clittle - 16 Jun 2015
Topic revision: r4 - 28 Jul 2015, clittle
This site is powered by FoswikiThe information you supply is used for OGC purposes only. We will never pass your contact details to any third party without your prior consent.
If you enter content here you are agreeing to the OGC privacy policy.

Copyright &© by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding OGC Public Wiki? Send feedback