Title: Intervisibility calculations for an orography by streaming service

Overview

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?

Actors

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.

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.

Requirements Issues/Discussion

  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
Edit | Attach | Print version | History: r2 < r1 | Backlinks | View wiki text | Edit WikiText | More topic actions...
Topic revision: r1 - 01 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