Title: Intervisibility calculations for an orography by streaming service

User Story

A user or system needs to use terrain information for analysis or visualisation. The user cannot wait for the entire dataset to download but does want to undertake numerous analysis tasks which mean that given communications bandwidth, reliability of connection, latency requirements etc, that caching terrain information on the client will allow the user to do more data intensive operations locally.


While much terrain processing can be undertaken at servers, there are situations where clients or other processing units wish to use terrain data. Reasons for accessing terrain data include:
  1. To underake processing which cant be centralised because the process requires data from multiple sources (e.g. terrain and weather data to calculate going).
  2. To allow caching of relevant data at different resolutions to meet specific needs. This allows devices to go off-line.
  3. To provide low latency access to data, for example to support 3D visualisation by streaming terrain to a visualisation
Clients need to be able to access the data at the resolution level they need, and the server needs to deliver the data very effiently to large numbers of clients. Typically orography calculations take three forms:
  1. Calculations related to individual points (what is the height/depth or slope at a point?
  2. Calculations along routes (on polylines), What is the terrain profile along a route?
  3. Calculations based on Areas. What grid points in an area can be seen from a given point at a given altitude?


Client User - Application Client such as a command and control system, or an intermediate processing node which agregates various sources.

Server - System serving the terrain data.


The client must have established a connection with the WC Tile Service using normal OGC Protocols.

Main Success Scenario

  1. Client identifies the area and resolution of terrain data needed.
  2. The client queries the server to identify the tile grid layout and resolutions available.
  3. The client requests tiles in the area and resolution it needs to generate the calculation.
  4. The client recieves the tiles and undertakes the calculation.

Alternative Paths

3a Client asks for lower resolution first to generate an initial view and then pulls tiles of higher resolution to 'back fill' and increase resolution.

Post Conditions

The client disconnects from the service. The client can maintain the cache if it wishes.


  1. To allow retrieval of terrain information in a gridded/mosaiced form with low latency.
  2. To allow fabric caching of the terrain to maximise performance from the server.
  3. To capature a 2d grid of properties including primary data such as terrain height and surface status,
  4. Allow out of date tiles in the cache to be identified.


  1. Why not leave the delivery of data to the server? The matrix set structure allows the client to ask for the data it wants, at a resolution it wants and in the order it wants. It can then do the calculation piecemeal. For example in doing intervisibility, the 4 tiles around the point allows the 'near' invisibiility can be calculated while waiting for the tiles further away to be downloaded. Also the server load is low and latency minimised because the web server is simple. So this model scales well.

-- Main.rbrackin - 01 Jun 2015
Topic revision: r2 - 30 Jun 2015, rbrackin
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