Nested environments

How the server handles plethora of multi-level defaults and localized preferences

Request for a weather product may include many parameters: grid, model, units, subgrid, etc.
These parameters can be decomposed into different layers of different scope
To make a request, one needs to submit only differences from previously stored profiles /preferences /defaults, rather than the whole set of parameters

Conceptual example

Server defaults:
  Units = *, model = nogaps, grid = grid_73x144
Client defaults (stored at the server as clients "profiles")
  for client id NDDH:
    units = ft, area = 75.000N 170.000W  031 063 02.5 02.5
    products = A01, C00
  for client id XAAZ 
    model = noraps, grid = grid_143x288
Product defaults:
  A01 name=pressures, units=mbars, model=nogaps
  C00 name=1000MB heights

Request from client NDDH (in the request.mfr-like format)
  CURRENTDTG
  A01 model=otis
  FINISH

The server would generate the following packed.dat file
  METXAREA 75.000N 170.000W  031 063 02.5 02.5
  METXA01
    75.000N 170.000W  031 063 02.5 02.5
    model=otis, grid = grid_73x144, units=mbars
  METXC00
    75.000N 170.000W  031 063 02.5 02.5
    model=nogaps, grid = grid_73x144, units=ft

Real Example

This is exactly how the vocabularies are stored and used

Voc(R): 2D_grid= "2D grid products" (
S,geom_name= "global_73x144"
S,model_name= "nogaps"
S,units_name= "*"
Voc(R): W= "flaps for NMC products" (
S,model_name= "NMC"
S,return_flaps_char= "W"
)
Voc(R): A01= "Surface Pressure" (
S,units_name= "mb"
)
Voc(R): A07= "Surface Air Temperature" (
S,model_name= "otis"
)
)

Advantages

- transmitting as few parameters in the request as possible

- sometimes, transmitting no parameters at all: I want my usual

- => easy broadcast (automatical periodical dissemination)

- changing the preferences is a snap: don't even need to recompile the project

The server has some set of defaults, say, the geometry grid is always grid_73x144, model is "nogaps", requested units "*" (meaning whatever the database has), etc. When the request from a client arrives, the server reads in defaults for that particular client. They might include an area the client is interested in, defaults for units (say, always "ft") and for the model (say, some particular client is interested only in NORAPS data). The client defaults always overwrite the server defaults. However, if some property is not specified by the client, the server defaults would apply. The request (made of one or several request lines) provides further details. Say, each line can specify the product name, the coordinates of the area the product is requested for (if different from the default), some other options, say, compression parameters for images. Note, the area should be specified only if it's different from the server/client defaults (request line information overrides all other defaults). Each product has its own set of defaults (say, preferred units), which overwrites the client/server defaults but can in turn be overwritten by request line options.

In this example, NDDH profile says that the client NDDH typically requests A01 and C00 products. Model for A01 is explicitly requested to be "otis", the model for C00 product is "nogaps", a server default. Units for C00 are ft (client default), units for A00 are mbars (product default). Note, the request from the NDDH client specifies only one product, yet two products, A01 and C00 are delivered - this is because the client profile says so. Moreover, the A01 product is specified in the request only because a non-standard model is requested. If the client were satisfied with the standard (for this product) model, no product needed be specified at all in the request. It means the NDDH client just needs "usual" data. Note, since defaults are hierarchical, it's easy to tinker with parameters for some particular product/client/request without infringing on other clients/products/requests.

So, this allows one to specify in the request as little information as possible (of course, nothing prohibits one from giving all possible information in the request). As we just have seen, it might happen that a request would contain no information at all: meaning the client just wants to get what is default for it. It also opens up a possibility for automatic sending of information to a client: one just needs to have a cron job that makes an empty request to the server on behalf of a specific client. Since the client defaults are kept in a separate file, it's possible to update the "client default region" automatically for some clients which are ships or can move otherwise. This provides for automatic weather info dissemination with tracking the current position of the client.

Next