• Table of Contents
• Product definition
  • Product configuration
    • Shared attributes
      • Time intervals
      • Clipping and margins
      • Output formatting
    • Product level attributes
    • Views
    • Layers
      • BackgroundLayer
      • MapLayer
      • LocationLayer
        • LabelConfig settings
      • IsobandLayer
      • IsolineLayer
        • isolines-attribute
      • IsolabelLayer
      • SymbolLayer
        • mindistance and priority
      • ArrowLayer
      • NumberLayer
      • NullLayer
      • CloudCeilingLayer
      • StreamLayer
      • RasterLayer
      • LegendLayer
      • TimeLayer
      • TagLayer
      • WKTLayer
      • HovmoellerLayer
      • GraticuleLayer
        • GraticuleLayer settings
        • Graticule settings
        • GraticuleLabels
      • CircleLayer
        • CircleLayer settings
        • Circle settings
        • CircleLabels settings
      • TranslationLayer
      • WindRoseLayer
      • OSMLayer
      • PostGISLayer
      • IceMapLayer
      • FinnishRoadObservationLayer
        • Algorithm to deduce weather condition symbol
      • PresentWeatherObservationLayer
        • Algorithm to deduce present weather symbol
      • MetarLayer
    • Structure definitions
      • Attribute structure
      • AttributeSelection structure
      • Projection structure
      • Defs structure
      • Smoother structure
    • Sampling structure
      • Heatmap structure
      • Isoband structure
      • Intersection structure
      • Isoline structure
      • Isofilter structure
      • LegendLabels structure
      • LegendSymbols structure
      • Text structure
      • Map structure
      • MapStyles structure
      • MapFeature structure
      • Positions structure
      • Label structure
      • LabelConfig structure
      • Location structure
      • Observation structure
      • Station structure
      • WindRose structure
      • Connector structure
      • Filters structure
• Using dynamically created grids
  • Introduction
  • Grids with the same timestamp
  • Grids calculated over multiple timesteps
  • Functions
• JSON references and includes
• Symbol substitutions via URI
• Dali querystring parameters
  • Product modification via querystring
  • Template selection
  • DataTile output
  • GetCapabilities
  • Debugging parameters
• WMS querystring parameters
• WMS GetMap and GetCapabilities configuration
  • WMS layer variants
• Configuration
  • Main configuration file
  • Plugin configuration file
    • Sample configuration file
• Examples
  • Map Projections
  • Dali Examples
  • WMS Examples
  • WMTS Examples
  • OGC Tiles Examples

Product definition

Product configuration

There can be thousands of different products defined for the Dali plugin. Each product has its own configuration file, which is used in order to define values for the attributes needed when constructing the final image. The table below shows an example of a product configuration file and the image that is returned when this product is requested.

{ // *** Product
  "title": "MyRedMap",
  "projection":
   {
     "xsize": 300,
      "ysize": 550,
      "crs": "EPSG:2393",
      "bboxcrs": "EPSG:4326",
      "cy": 64.8,
      "cx": 25.4,
      "resolution": 2.5
   },
   "views": [
       {  // *** View 1
       "layers": [
        { // **** Layer 1 : Light blue background
           "layer_type": "background",
           "attributes":
           {
               "stroke": "none",
               "fill": "rgb(190,230,255)"
           }
        },
        { // ***  Layer 2 : Red map with black borders
           "layer_type": "map",
           "map":
          {
            "schema": "natural_earth",
            "table": "europe_country_wgs84"
           },
           "attributes":
           {
            "class": "Europe",
            "stroke": "black",
            "stroke-width": "0.5",
            "fill": "rgb(255,0,0)"
           }
        }
       ]
     }
    ]
}

The product configuration files are written in Java Script Object Notation (JSON). In order to create your own product configuration files you just need to know what attributes are used on different configuration levels, i.e., what attributes can be given on the product level, on the view level and on the layer level. These attributes are described flater in this chapter.

The attribute description for each attribute consists of the attribute name, the attribute type, the default value and a short description of the attribute usage. In the attribute description the attribute type can be defined in the following ways:

Shared attributes

There are some upper level attributes that can be used also on the lower level in the hierarchy. For example, some attributes defined on the product level are visible also on the view and layer levels. These levels can directly use these upper level attribute values or override the values with their own values. These attributes can be overridden also by the request parameters. For example, the "language" attribute can be overridden by using the "language" parameter in the request.

The table below contains a list of attributes that are shared from the top level to the lower levels.

Shared attributes 

Time intervals

Normally the "valid time" for the data is time + time_offset. If a time interval is defined, it is producer dependent how the settings are interpreted. Most layers ignore the settings, and the settings are ignored for all forecasts. For lightning data the interval is true, all flashes in the interval are picked. For other observations only the latest one in the time interval will be selected. For this reason interval_end is usually not needed for observations either.

Clipping and margins

Normally any point strictly outside the layer rectangle will be omitted. However, if the image will be tiled, this may produce images where symbols or text appear only in one tile, and the rest of the symbol is cut off from the adjacent tile. The layer effective bounding box may be expanded using the setting "margin", which sets both the x-margin and y-margin, or directly by setting "xmargin" and/or "ymargin".

For observations any point inside the expanded area will be included. Typically one would expand the layer by half the size of any symbol needed in the image, be it a symbol, a number or whatever. The marging has an effect also on geometries. For example if one wishes to draw isolines with a line a few pixels wide, the margings should be expanded accordingly.

For tiled images expanding the area has no discernible effect, since the clipping will be automatic since the rendered image is still the expected size and does not include the margins. However, if one has multiple views in a single image, one should set "clip" to true to make sure none of the layers leak outside their respective areas. Using a clipPath slows rendering down a little, hence it is not on by default.

Output formatting

Most output types (svg, png, pdf, ps, geojson, topojson, kml) are rendered through the CTPP/SVG pipeline. Three output types bypass this pipeline entirely: geotiff returns raw float data via GDAL, mvt returns protobuf-encoded Mapbox Vector Tiles, and datatile returns RGBA-encoded float data as standard PNG (see DataTile output).

PNG output formatting can be tuned using the following settings inside a top level "png" tag:

WebP output uses the same color reduction settings from the "png" tag, and adds its own compression speed and animation controls in a top level "webp" tag:

WebP time animation

When "frames" is set and the output type is webp, layers supporting time animation divide the layer time interval (see Time intervals) into the given number of frames, and each rendered element is assigned to a frame based on its actual observation time. The frames are then encoded into a single looping animated WebP image. All other layers (backgrounds, maps etc.) render identically into every frame.

Currently the symbol-layer observation rendering supports time animation, the main use case being lightning data: with for example "interval_start": 30, "interval_end": 30 and "frames": 6, each frame replays ten minutes of flash strokes in stroke time order. Setting "accumulate": true makes the strokes pile up during the loop instead, which shows where lightning activity has moved during the interval. A typical flash layer interval is 5, 15, 30 or 60 minutes to match the available radar data time period.

The SVG content is generated only once; each frame is rasterized from the same SVG with a different visibility selection, so rendering cost grows only with rasterization and encoding, not with data queries. Note that this product-level setting is separate from the WMS GetMap "animation" block, which animates over consecutive valid times.

Product level attributes

The product level is the highest structural level used in the product configuration file. The product attributes are used in order to define product level properties for the current product. On the other hand, the product attributes define the substructures related to the current product.

The table below contains a list of attributes that can be defined for the product.

Product 

Views

A product can contain several views that are merged together into single image / product. The product level attribute "views" are used in order to define an array of the View structures for the product. Each view must have its own View structure in this array. The View structure is used in order to define the view level attributes and the lower level structures (i.e. layers).

The table below contains a list of attributes that can be defined in the View structure.

View

Layers

A view can contain several layers that are merged together into single view. The view level attribute "layers" are used in order to define an array of the Layer structures for the view. Each layer must have its own Layer structure in this array. The Layer structure is used in order to define layer level properties. The most important attribute on the layer level is the "layer_type" attribute, which defines the type of the current layer. At the same time it defines indirectly which layer module the Dali plugin should use to create an image for the current layer. On the other hand, the layer type tells us which other attributes we should define for the current layer. In other words, if the layer type is for example "isoband" then we should define on this level also all isoband layer related attributes. All the layers share some common attributes. In addition, each layer type has its own attributes. The table below contains a list of attributes that are common in all layers.

Layer

Notice that the term "resolution" used above might be a little bit misleading in this case, since it refers to the number of kilometers represented by one pixel. Hence the higher the resolution the worse the accuracy of the image actually is. The actual condition to be satisfied is minresolution <= resolution < maxresolution, where one or both of the limits may be missing.

BackgroundLayer

The background layer is used to create a background for the current view. So it is usually the lowest layer in the view.

The table below shows a simple example on the usage of the background layer.

Product configuration file	Produced image layer
{ // *** Product "title": "MyLightBlueBackground", "projection": { "xsize": 300, "ysize": 550, "crs": "EPSG:2393", "bboxcrs": "EPSG:4326", "cy": 64.8, "cx": 25.4, "resolution": 2.5 }, "views": [ { // *** View 1 "layers": [ { // **** Layer 1 : Light blue background "layer_type": "background", "attributes": { "stroke": "none", "fill": "rgb(190,230,255)" } } ] } ] }

The background layer has no attributes than the generic Layer or Properties attributes. The layer exists merely to obtain the "xsize" and "ysize" attribute values for a rectangle element so that the background can be filled with a value.

MapLayer

The table below shows a simple example on the usage of the map layer.

Product configuration file	Produced image layer
{ // *** Product "title": "MyMap", "projection": { "xsize": 300, "ysize": 550, "crs": "EPSG:2393", "bboxcrs": "EPSG:4326", "cy": 64.8, "cx": 25.4, "resolution": 2.5 }, "views": [ { "layers": [ { "layer_type": "map", "map": { "schema": "natural_earth", "table": "europe_country_wgs84" }, "attributes": { "class": "Europe" } } ] }] }

The table below contains a list of attributes that can be defined for the map layer in addition to the common layer attributes.

MapLayer

LocationLayer

The location layer renders point symbols at geographic positions retrieved from the geonames database. Typical use: city dots on a weather map so the viewer can locate the weather data. Location names are context for the weather information — weather symbols always take visual priority.

Symbols are selected by population and geonames feature code using the AttributeSelection mechanism. An optional label block renders the location name as an SVG text element next to the symbol using one of several cartographic label-placement algorithms.

Layer ordering and weather priority. Because location labels are context rather than primary data, place the location layer before weather layers in the views.layers array so that weather symbols render on top. The label halo (white stroke) keeps text legible even when a weather symbol overlaps it.

The table below shows a simple example of the location layer with greedy label placement.

Product configuration file

Produced image layer

{ // *** Product "title": "MyCities", "projection": { "xsize": 300, "ysize": 550, "crs": "EPSG:2393", "bboxcrs": "EPSG:4326", "cy": 64.8, "cx": 25.4, "resolution": 2.5 }, "views": [ { "layers": [ { // *** Layer 1: Map background "layer_type": "map", "map": { "schema": "natural_earth", "table": "europe_country_wgs84" }, "attributes": { "class": "Europe" } }, { // *** Layer 2: Cities with labels "qid": "cities", "layer_type": "location", "keyword": "ely_cities", "css": "maps/map.css", "mindistance": 20, "symbols": { "default": [ { "hilimit": 1000000, "symbol": "city" }, { "lolimit": 1000000, "symbol": "bigcity" } ], "PPLC": [ { "symbol": "capital" } ] }, "label": { "algorithm": "greedy", "candidates": 8, "offset": 4, "font_family": "sans-serif", "font_size": 10, "fill": "#333333", "stroke": "white", "stroke_width": 2, "stroke_opacity": 0.8, "classes": [ { "lolimit": 500000, "font_size": 13, "font_weight": "bold" } ] } } ] } ] }

The table below lists the attributes that can be defined for the location layer in addition to the common layer attributes.

LocationLayer

SVG symbols requirements. All <symbol> definitions referenced from the location layer must (1) place their geometry around the origin (e.g. cx="0" cy="0" for a circle, or x="-N" y="-N" for a rect) and (2) declare overflow="visible". The plugin renders <use x="..." y="..."/> at each location's projected anchor; symbols with non-origin geometry shift off-anchor, and symbols without overflow="visible" get clipped by the implicit symbol viewport. See the test products under test/dali/customers/test/products/location_labels_*.json for the required pattern.

Render order. Within the location layer, labels are emitted first (halo + fill) and markers last, so the marker stays visually clean even when the label halo would otherwise bleed onto it. Labels and markers for the same candidate render in reverse-priority order (highest-priority last) so on overlap the more important label stays on top. A marker is suppressed when its label is dropped — an isolated marker on a dense map is unreadable.

LabelConfig settings

The label object configures how location names are placed as SVG text next to their symbols. All label rendering happens inside the same SVG group as the symbols, so labels appear above symbols within the group but below layers placed after the location layer in the product.

The placement algorithms come from the cartographic literature. For most weather map use cases greedy (k=8) gives the best quality-to-cost ratio. Use simulated-annealing when label density is high and overlap quality matters more than rendering time.

LabelConfig — common settings

classes array entries (population-range style overrides):

Algorithm comparison gallery — same dataset (Finnish municipalities), same projection, different placement settings. See labeling_algorithms.md for the underlying theory.

fixed NE position for everyone, no conflict avoidance. Drops labels that would cover another marker.	greedy Imhof preference order, first non-overlap wins. Geonames priority order.	priority-greedy Same as greedy but candidates pre-sorted by population descending.
simulated-annealing Global label-overlap minimisation. Best results for dense urban areas.	greedy + free-space bias free_space_weight: 1.5, free_space_radius: 120 Coastal cities push labels into the sea.	SA + free-space bias Same bias on top of SA's overlap optimisation.
priority-greedy + bucketing priority_bucket_ratio: 2.0 Close-population cities tied; shorter label wins.	greedy + pan-invariant pan_invariant: true Centred on Jyväskylä.	same, bbox shifted +0.5° Cities visible in both panned views land at identical offsets from their markers (verified per-city).

Algorithm-specific settings:

fixed — Places every label at a single predetermined position relative to its symbol. No label-vs-label conflict detection (labels may overlap each other), but a label that would cover another marker is dropped — and that candidate's marker is dropped with it. Processes candidates in priority order so the highest-priority kept entry always wins.

greedy — For each location in geonames priority order (highest-priority city first), tries up to candidates positions and places the label at the first position that does not overlap any already-placed label and fits within the map bounds. Dropped labels have no text rendered. This is the recommended algorithm for most weather map use cases.

priority-greedy — Identical to greedy but the input is re-sorted by population descending before placement. Use this when you need to guarantee that the largest cities get labels regardless of their geonames autocomplete rank.

simulated-annealing — Global near-optimum placement based on Christensen, Marks & Shieber (1995). Minimises total label-overlap area across all labels simultaneously. Slower than greedy (configurable number of iterations) but produces noticeably better results for dense urban areas. The RNG seed is fixed, so output is deterministic and the HTTP response cache works correctly.

LabelConfig — simulated-annealing sub-object

Example — simulated annealing with population-scaled labels:

"label": {
  "algorithm": "simulated-annealing",
  "candidates": 8,
  "offset": 4,
  "font_family": "sans-serif",
  "font_size": 10,
  "fill": "#222222",
  "stroke": "white",
  "stroke_width": 2.5,
  "stroke_opacity": 0.75,
  "max_labels": 150,
  "simulated_annealing": {
    "iterations": 2000,
    "initial_temperature": 1.0,
    "cooling_rate": 0.99,
    "overlap_weight": 1.0,
    "position_weight": 0.2
  },
  "classes": [
    { "lolimit": 500000, "font_size": 13, "font_weight": "bold", "fill": "#111111" },
    { "lolimit":  50000, "font_size": 11 }
  ]
}

IsobandLayer

The isoband layer can be used to add filled contours (= isobands) to the view. Isobands can be used for presenting several kinds of data such as temperatures, rain amounts, cloudiness, ice cover, flash heatmap etc.

The tables below show simple examples on the usage of the isoband layer.

Product configuration file

Produced image layer

{ // *** Product "title": "MyCloudiness", "projection": { "xsize": 300, "ysize": 550, "crs": "EPSG:2393", "bboxcrs": "EPSG:4326", "cy": 64.8, "cx": 25.4, "resolution": 2.5 }, "views": [ { // *** View 1 "layers": [ { // *** Layer 1 : Cloudiness "layer_type": "isoband", "isobands": "json:isobands/cloudiness.json", "css": "isobands/cloudiness.css", "parameter": "TotalCloudCover", "multiplier": 0.0898, "offset" : -0.49, "attributes": { "shape-rendering": "crispEdges" } } ] } ] }

/td>

Product configuration file

Produced image layer

{ // *** Product "title" : "Lightning heatmap for 15 minute period", "abstract" : "Lightning heatmap for 15 minute period", "interval_start": 15, "interval_end": 15, "projection": { "crs": "EPSG:4326", "cx" : 25, "cy" : 65, "resolution" : 5, "xsize": 500, "ysize": 500 }, "producer": "flash", "views": [{ "layers": [ { "qid": "l", "layer_type": "isoband", "parameter": "peak_current", "isobands": "json:isobands/heatmap.json", "css": "isobands/heatmap.css", "attributes": { "shape-rendering": "crispEdges" }, "heatmap" : { "resolution" : 10, "radius" : 10, "kernel" : "exp", "deviation" : 10.0 } }, { "qid": "l1", "layer_type": "map", "map": { "schema": "natural_earth", "table": "admin_0_countries", "minarea": 100 }, "attributes": { "id": "europe_country_lines", "fill": "none", "stroke": "#222", "stroke-width": "0.3px" } } ] }] }

The table below contains a list of attributes that can be defined for the isoband layer in addition to the common layer attributes.

IsobandLayer

In automatic qid and class generation "." will be replaced by ",", since "." is reserved for JSON paths. If both the lower limit and upper limit are undefined, "nan" will be used to fill the pattern. If only the lower limit is missing, "-inf" will be used. If only the upper limit is missing, "inf" will be used.

IsolineLayer

The isoline layer can be used to add isolines to the view. Isolines can be used to present several kinds of data like pressure variations, altitude variations, etc.

The table below shows a simple example on the usage of the isoline layer.

Product configuration file

Produced image layer

{ // *** Product "title": "MyPressure", "projection": { "xsize": 300, "ysize": 550, "crs": "EPSG:2393", "bboxcrs": "EPSG:4326", "cy": 64.8, "cx": 25.4, "resolution": 2.5 }, "views": [ { // *** View 1 "layers": [ { // *** Layer 1 : Map "layer_type": "map", "map": { "schema": "natural_earth", "table": "europe_country_wgs84" }, "attributes": { "class": "Europe" } }, { // *** Layer 2 : Isoline "layer_type": "isoline", "isolines": "json:isolines/pressure.json", "css": "isolines/pressure.css", "parameter": "Pressure", "attributes" : { "class" : "Pressure" } } ] } ] } }

The table below contains a list of attributes that can be defined for the isoline layer in addition to the common layer attributes.

IsolineLayer

In automatic qid/class generation "." will be replaced by ",", since "." is reserved for JSON path definitions.

isolines-attribute

Isolines are defined by using isolines-attribute. There are two alternative ways to define the attribute

1. Define explicitly array of Isoline structures

Example:

"isolines":
{
[
    {
        "qid": "pressure_950",
        "value": 950,
	"attributes": {}
    },
    {
        "qid": "pressure_960",
        "value": 960,
	"attributes": {}
    },
    {
        "qid": "pressure_970",
        "value": 970,
	"attributes": {}
    },
    {
        "qid": "pressure_980",
        "value": 980,
	"attributes": {}
    },
    {
        "qid": "pressure_990",
        "value": 990,
	"attributes": {}
    },
    {
        "qid": "pressure_1000",
        "value": 1000,
	"attributes": {}
    },
    {
        "qid": "pressure_1010",
        "value": 1010,
	"attributes": {}
    },
    {
        "qid": "pressure_1020",
        "value": 1020,
	"attributes": {}
    },
    {
        "qid": "pressure_1030",
        "value": 1030,
	"attributes": {}
    },
    {
        "qid": "pressure_1040",
        "value": 1040,
	"attributes": {}
    },
    {
        "qid": "pressure_1050",
        "value": 1050,
	"attributes": {}
    },
]
}

2. Define set of parameters which are used to generate Isoline structures. The following parameters must be defined:

Example:

                {
		    "qid": "l4",
                    "layer_type": "isoline",
                     "isolines": 
		    {  
			"qidprefix": "isoline_main_", 
			"startvalue": 900, 
			"endvalue": 1100,
			"interval": 5
		    },
                    "css": "isolines/pressure.css",
                    "parameter": "Pressure",
		    "attributes":
		    {
			"fill": "none",
			"stroke": "#333",
			"stroke-width": "1.5px"
		    }
                },
                {
		    "qid": "l5",
                    "layer_type": "isoline",
                    "isolines": 
		    {  
			"qidprefix": "isoline_sub_", 
			"startvalue": 900, 
			"endvalue": 1100,
			"interval": 2,
			"except": 5
		    },
                    "css": "isolines/pressure.css",
                    "parameter": "Pressure",
		    "attributes":
		    {
			"fill": "none",
			"stroke": "red",
			"stroke-dasharray": "10,5",
			"stroke-width": "1.0px"
		    }
		}

TFP metaparameter (isoband and isoline layers)

Both IsobandLayer and IsolineLayer accept "parameter": "TFP" as a metaparameter that causes the layer to compute Hewson's Thermal Front Parameter on the fly from an underlying scalar field before contouring. This is intended as a diagnostic display — a clean isoband plot of TFP is one of the standard forecaster tools for spotting frontal zones, moisture boundaries, jet-stream edges, and so on. It makes no binary "is there a front here" decisions.

The underlying scalar field is configured in a "tfp" block on the layer:

TFP has units of (units of field) / m². For potential temperature that's K/m²; Hewson scales by (100 km)² so "1 unit" in his paper equals 10⁻¹⁰ K/m². The supplied test CSS (isobands/tfp.css) uses that scale.

Which underlying field to use depends on what you want to see:

If you want objective front detection (not just a diagnostic display), the most complete open implementation is Spensberger's dynlib (University of Bergen; Fortran with Python bindings, includes Hewson-style routines tuned against ERA5 climatologies). Schemm, Sprenger & Wernli 2018 is a simpler first-derivative alternative based on |∇θe|. Neither is wrapped into this plugin; they would be the natural starting points if automatic detection ever becomes a requirement.

Example (TFP of θ at 850 hPa):

{
    "layer_type": "isoband",
    "parameter": "TFP",
    "level": 850,
    "tfp":
    {
        "field": "PotentialTemperature",
        "smoothing_passes": 3
    },
    "css": "isobands/tfp.css",
    "isobands": "json:isobands/tfp"
}

IsolabelLayer

The isolabel layer is derived from the isoline layer, and thus inherits all its settings. The settings below are then available for positioning isovalues on the isolines. It is also possible to refer to the isolines that would be generated by an isoband layer, or to list to generate isovalues explicitly without referring to another layer.

IsolabelLayer

The isovalues parameter may also be a JSON object with start, stop and step (default=1) doubles.

The placement algorithm — multi-angle local-extremum scan, divisibility-weighted MST selection, data-probed orientation — is documented in isolabel_algorithms.md, with a gallery of rendered tests showing each tunable in action.

SymbolLayer

The symbol layer can be used to add different kinds of symbols to the view. The symbols are added at the given locations and the type of the symbol depends on the value of the field defined by the "parameter" attribute. The actual symbol figures are stored in the file systems s SVG images.

The table below shows a simple example on the usage of the symbol layer.

Product configuration file

Produced image layer

{ // *** Product "title": "MyWeatherSymbols", "refs": { "myprojection": "json:maps/finlandprojection.json", "finland": { "schema": "natural_earth", "table": "finland_country_wgs84", "minarea": 100, "mindistance": 1 } }, "projection": "ref:refs.myprojection", "views": [ { "attributes": { "id": "view1" }, "layers": [ { "layer_type": "map", "map": { "schema": "natural_earth", "table": "finland_country_wgs84", "minarea": 80, "mindistance": 5 }, "attributes": { "id": "europe_country_lines", "fill": "none", "stroke": "#666", "stroke-width": "0.5pt" } }, { "layer_type": "symbol", "css": "symbols/weather.css", "symbols": "json:symbols/weather.json", "parameter": "weathersymbol", "scale": 1.25, "positions": { "layout": "latlon", "locations": [ { "longitude": 24.93417, "latitude": 60.17556 }, { "longitude": 28.27838, "latitude": 61.02292 }, { "longitude": 21.85943, "latitude": 61.57477 }, { "longitude": 25.60742, "latitude": 62.20806 }, { "longitude": 27.89568, "latitude": 62.94718 }, { "longitude": 23.13066, "latitude": 63.83847 }, { "longitude": 27.40756, "latitude": 64.13355 }, { "longitude": 24.56371, "latitude": 65.73641 }, { "longitude": 28.15806, "latitude": 67.29250 }, { "longitude": 24.15138, "latitude": 67.60517 }, { "longitude": 27.02881, "latitude": 68.90596 } ], "dx": -20, "dy": -20 } }] }] }

The table below contains a list of attributes that can be defined for the symbol layer in addition to the common layer attributes.

SymbolLayer 

Note that assigning a proper scale for symbols with CSS or SVG attributes alone is difficult. Using the scale-attribute eases the scaling of the symbols.

Observation symbols (in particular lightning data) can be replayed in observation time order as an animated WebP image by setting "frames" in the product level "webp" tag, see WebP time animation.

mindistance and priority

Allowed priority values

Symbols are drawn on the map starting from the highest priority. If there already is a symbol nearby on the map (mindistance parameter), the symbol is not shown. Regarding mindistance and priority parameters the same logic is applied in Arrow-, Number- and CloudCeilingLayers.

ArrowLayer

The arrow layer is usually used for showing wind directions on the map. Technically it can be used for showing all kinds of directions.

The table below shows a simple example on the usage of the arrow layer.

Product configuration file

Produced image layer

{ // *** Product "title": "MyWindDirections", "projection": { "xsize": 300, "ysize": 550, "crs": "EPSG:2393", "bboxcrs": "EPSG:4326", "cy": 64.8, "cx": 25.4, "resolution": 2.5 }, "views": [ { // *** View 1 "layers": [ { // *** Layer 1 : Map "layer_type": "map", "map": { "schema": "natural_earth", "table": "europe_country_wgs84" }, "attributes": { "class": "Europe" } }, { // *** Layer 2 :Wind arrows "layer_type": "arrow", "css": "arrows/windarrow.css", "direction": "WindDirection", "speed": "WindSpeedMS", "attributes": { "id": "wind_arrows", "class": "WindArrow", "mask": "url(#windlegendmask)" }, "arrows": "json:arrows/windarrow.json", "positions": { "x": 5, "y": 5, "dx": 30, "dy": 30, "ddx": 15 } } ] } ] }

The table below contains a list of attributes that can be defined for the arrow layer in addition to the common layer attributes.

ArrowLayer 

Note: A direction parameter is sufficient to draw arrows. An additional speed component may be defined to style the arrows depending on the speed. Both U- and V-components must be specified if used, but these cannot be used simultaneously with the direction and speed parameters.

NumberLayer

The number layers is used to add numerical values for temperatures, pressures, rain amounts, etc. in the view.

The table below shows a simple example on the usage of the number layer.

Product configuration file

Produced image layer

{ // *** Product "title": "Temperature Overlay", "refs": { "myprojection": "json:maps/finlandprojection.json" }, "projection": "ref:refs.myprojection", "views": [ { // *** View 1 "layers": [ { // *** Layer 1 : Map "layer_type": "map", "map": { "schema": "natural_earth", "table": "europe_country_wgs84" }, "attributes": { "class": "Europe" } }, { // *** Layer 2 : Numbers "layer_type": "number", "css": "numbers/numbers.css", "parameter": "Temperature", "attributes": { "class": "Number", "mask" : "url(#legendmask)" }, "label": "json:numbers/integers.json", "positions": { "x": 20, "y": 18, "dx": 30, "dy": 30, "ddx": 15 } } ] } ] }

The table below contains a list of attributes that can be defined for the number layer in addition to the common layer attributes.

NumberLayer 

NullLayer

Null layers are merely placeholders for definitions which will be inserted into the block if a suitable STYLES option is used and the qid settings match. Sample use cases for null layers include

• enabling numbers over isobands
• enabling symbols over the underlying image
• enabling arrows over isobands
• enabling isolabels over isobands

CloudCeilingLayer

The cloud_ceiling layer is used for cloud ceiling observations (ie. the height of the base of the lowest clouds when the cloud amount is more than falf of the sky: broken, overcast or obscured)

The table below shows a simple example on the usage of the cloud_ceiling layer.

Product configuration file

Produced image layer

{ "title": "Cloud Ceiling", "abstract": "Cloud ceiling from FMI's AWS-stations", "producer": "observations_fmi", "interval_start": 15, "interval_end": 0, "language": "fi", "projection": {}, "views": [{ "qid": "v1", "attributes": { "id": "view1" }, "layers": [ { "qid": "finland", "layer_type": "map", "map": { "schema": "natural_earth", "table": "admin_0_countries", "where": "iso_a2 IN ('FI','AX')" }, "attributes": { "id": "finland_country", "fill": "rgb(255, 255, 204)" } }, { "qid": "finland-roads", "layer_type": "map", "map": { "schema": "esri", "table": "europe_roads_eureffin", "where": "cntryname='Finland'", "lines": true }, "attributes": { "class": "Road" } }, { "qid": "borders", "layer_type": "map", "css": "maps/map.css", "map": { "lines": true, "schema": "esri", "table": "europe_country_wgs84", "mindistance": 2.5, "minarea": 10 }, "attributes": { "class": "Border", "id": "BorderMap" } }, { "qid": "cities", "layer_type": "location", "keyword": "ely_cities", "css": "maps/map.css", "symbols": { "default": [ { "symbol": "city" } ] } }, { "qid": "cloud_ceiling_observations", "layer_type": "cloud_ceiling", "keyword": "synop_fi", "priority": "min", "mindistance": 35, "attributes": { "fill": "rgba(0,0,255,1.00)", "font-family": "Verdana", "font-size": "16px", "text-anchor": "middle", "stroke": "#000000", "stroke-width": 0.5 }, "label": { "padding_char": "0", "padding_length": 3, "missing": "-", "multiple": 100, "dx": 6, "dy": -10, "rounding": "towardzero" } } ] }] }

The cloudceiling layer is inherited from number layer so the same attributes are available. Label object has two new attributes 'padding_char' and 'padding_length' to format numbers.

StreamLayer

The streamline layer is used for visualizing directional parameters such as wind direction, wave direction, ice drift direction etc.

The table below contains a list of attributes that can be defined for the streamline layer in addition to the common layer attributes.

StreamLayer 

RasterLayer

The core concept of a raster layer is to render an image from a set of grid-based values, where each grid cell corresponds to a pixel in the resulting raster image. The color of each pixel is determined by mapping its associated value to a position within a predefined color map. This color map is essentially a list of value-color pairs, allowing for the identification of lower and upper bounds for each input value, along with their associated colors. By default, the final color is computed via linear interpolation between these bounds on a per-channel basis (A, R, G, B), resulting in a smooth color gradient. This technique eliminates hard boundaries between value regions, yielding a more continuous and visually intuitive representation.

The value-to-color mapping is handled by so-called painter elements, which can vary in type. The current implementation supports the following painter types.

1. Painter: "default"
   The "default" painter, utilizes a full value-to-color list to perform interpolation across multiple defined intervals. The relationships between values and the colors are defined in the colormap file. It is also possible to use colors without interpolation (smooth_colors=false), which makes them look like the vector based isobands.

2. Painter: "range" The "range" painter functions almost similarly as the "default" painter. The difference is that the value ranges are part of the layer definition. Each range contains the minimum and maximum values of the dataset, along with their corresponding colors. In addition a range definition can contain colors that should be used above or below the given range. Usually this is the fastest way to define simple color ranges. For example, clouds can be painted so that only the opacity of the white color is changed according to the cloud coverage percent.

3. Painter: "stream" The "stream" painter has the same idea as the Stream Layer, but the stream lines are drawn by using raster points. The direction of the stream lines are painted by using the variation of the alfa channel. Notice that the "stream" painter is capable for painting animation steps, which means that it can paint stream lines differently in each loop steps. This creates a moving effect when multiple images are put into the same animation file (WebP -file). It is also possible to make stream lines move faster in certain areas and this way simulate different stream speeds in different areas.

4. Painter: "border" The "border" painter can be used for painting different kinds of border lines (like isolines). The current painter paints each border by using two colors: inside color and the outside color. This improves their visibility. For example, if the inside color is white and the outside color is black, then the border should be visible almost everywhere, because the background color cannot be dark and light at the same time. Notice that the "border" painter is also used as an additional painter for each layer. This means that in spite of that we have selected the "master painter" to be "default","range" or "stream", we can use the "border" painter with the same parameter. For example, if we use the "range" painter to paint clouds, we might want to make cloud borders more visible by using "data_borders" definition with the current painter. This definition contains the same attributes that would be given normally to the "border" painter.

5. Painter: "shadow" The "shadow" painter can be used for painting shadows for the actual data. For example, we can paint shadows for clouds or raining areas. The basic idea is that we pick data ranges from the actual and paint this data with party transparent colors. In addition we shift these areas so that they are painter a little bit different location than the original data. This creates quite nice shadow effects. Notice that the "shadow" painter is also used as an additional painter for each layer. This means that in spite of that we have selected the "master painter" to be "default","range" or "stream", we can use the "shadow" painter with the same parameter. For example, if we use the "range" painter to paint clouds, we might want to create some shadows for these cloud by using "data_shadows" definition with the current painter. This definition contains the same attributes that would be given normally to the "shadow" painter.

Product configuration file

 {
  "title": "Temperature",
  "abstract": "Temperature",
  "source": "grid",
  "producer": "ec",
  "projection": {},
  "animation" :
  {
    "enabled"           : false,  // Enables/disables the animation
    "timesteps"         : 24,     // Number of animation timesteps
    "timestep_interval" : 90,     // Frame interval time (= milliseconds) between timesteps
    "data_timestep"     : 20,     // Timestep length (= minutes)in in the actual data
    "loopsteps"         : 1,      // Number of animation steps inside the same timestep
    "loopstep_interval" : 70      // Frame interval time (=milliseconds) between loopsteps
  },

  "views": 
  [
    {
      "layers":
      [
        {
          // ************************************************************
          //  Temperature
          // ************************************************************
          //  This demonstrates the usage of the "default" data painter,
          //  which paints data values according to color definitions
          //  specified in the "colormap" file.
          // ************************************************************

          "layer_type"            : "raster",
          "qid"                   : "temperature-1",
          "compression"           : 1,
          "visible"               : true,
          "parameter"             : "temperature",
          "interpolation"         : "linear",
          "data_painter"          : "default",
          "data_opacity_land"     : 1.0,
          "data_opacity_sea"      : 1.0,
          "colormap"              : "temperature",
          "smooth_colors"         : true,

          "land_position"         : "bottom",
          "land_color"            : "FFD0D0D0",

          "sea_position"          : "top",
          "sea_color"             : "FFCCE0F8",

          "land_border_position"  : "none",
          "land_border_color"     : "80000000",
          "sea_border_color"      : "80FFFFFF",

          "land_shading_position" : "top",
          "land_shading_light"    : 128,
          "land_shading_shadow"   : 384,

          "sea_shading_position"  : "top",
          "sea_shading_light"     : 128,
          "sea_shading_shadow"    : 384
        }
        ,
        {
          // ************************************************************
          //  High clouds 
          // ************************************************************
          //  This demonstrates the usage of the "range" data painter,
          //  which is almost the same as the "default" data painter. The
          //  main diffence is that it does not have colormaps, but it
          //  defines similar color ranges in the "ranges" array. In 
          //  addition it can define colors that are outside of the given
          //  range (color_low,color_high). This is a fast way to define
          //  colors for data that does not require many color ranges.
          //
          //  Notice that in this example we use interpolation method
          //  "transfer" that tries to calculate cloud transitions
          //  with a different algorithm (i.e. it does not use linear
          //  interpolation. The same algorithm can be used with rain.
          // ************************************************************

          "layer_type"            : "raster",
          "qid"                   : "high-clouds-1",
          "visible"               : true,
          "compression"           : 1,
          "parameter"             : "NH-PRCNT:ECGMTA:1008:6:0:1",
          "interpolation"         : "transfer",
          "data_painter"          : "range",
          "data_opacity_land"     : 1.0,
          "data_opacity_sea"      : 1.0,

          "ranges" : [
            {
              "value_min"         : 10,
              "value_max"         : 100,
              "color_min"         : "20FFFFFF",
              "color_max"         : "FFFFFFFF",
              "color_low"         : "00000000",
              "color_high"        : "00000000"
            }
          ]
          ,
          "data_shadows" : [
            {
              "value_min"         : 20,
              "value_max"         : 100,
              "color_min"         : "30000000",
              "color_max"         : "30000000",
              "dx"                : 5,
              "dy"                : 5
            }
          ]
          ,
          "land_position"         : "none",
          "land_color"            : "FF404040",

          "sea_position"          : "none",
          "sea_color"             : "FFCCE0F8",

          "land_border_position"  : "top",
          "land_border_color"     : "20000000",
          "sea_border_color"      : "20FFFFFF",

          "land_shading_position" : "none",
          "land_shading_light"    : 256,
          "land_shading_shadow"   : 384,

          "sea_shading_position"  : "none",
          "sea_shading_light"     : 128,
          "sea_shading_shadow"    : 384
        }
      ]
    }
  ]
} 

The table below contains a list of attributes that can be defined for the raster layer in addition to the common layer attributes.

RasterLayer 

The raster layer can paint land and sea colors above or below of the painted parameter. This allows you to create some nice effects. For example, if you want to make sea areas darker than the land areas the you can paint sea areas above the parameter layer by using colors with some transparency (for example 20000000).

The raster layer can paint topographical shadings above or below the painted parameter.

The raster layer can create borders for the actual parameter. Technically this uses the "border" painter functionality, but in this case is more like an addition to the current painter.

The raster layer can create shadows for the actual parameter. Technically this uses the "shadow" painter functionality, but in this case is more like an addition to the current painter.

Attributes for the painter "default".

Attributes for the painter "range".

Attributes for the "range" structure.

Attributes for the painter "stream".

Stream lines can use colors for indicating the speed of the stream. In this case the 'parameter' attribute is replaced with 'speed' and 'direction' attributes. In addition, the 'colormap' attribute is used for selecting stream color according to the speed value.

If the data is given as 'parameter' attribute (without speed information) then the painter needs line colors.

Attributes for the "border" painter.

Attributes for the "border" structure.

Attributes for the "shadow" painter.

Attributes for the "shadow" structure.

LegendLayer

The legend layer can be used to define legends for the colors or symbols used in the product.

The table below shows a simple example on the usage of the legend layer.

Product configuration file

Produced image layer

{ // *** Product "title": "MyLegendLayer", "refs": { "myprojection": { "xsize": 300, "ysize": 550, "crs": "EPSG:2393", "bboxcrs": "EPSG:4326", "cy": 64.8, "cx": 25.4, "resolution": 2.5 } }, "defs": { "styles": { ".Label": { "font": "Arial", "font-size": 9 }, ".Units": { "font": "Arial", "font-size": 11 } }, "layers": [ { "tag": "symbol", "attributes": { "id": "rect" }, "layers": [ { "tag": "rect", "attributes": { "width": "14", "height": "12"} } ] }, { "tag": "symbol", "attributes": { "id": "uptriangle" }, "layers": [ { "tag": "path", "attributes": {"d": "M0 12,7 0,14 12Z"} } ] } ] }, "projection": "ref:refs.myprojection", "views": [ { // *** View 1 "layers": [ { // *** Layer 1 : Wind speed labels "layer_type": "legend", "x": 10, "y": 10, "dx": 0, "dy": 12, "isobands": "json:isobands/wind.json", "symbols": { "css": "isobands/wind.css", "symbol": "rect", "start": "uptriangle", "attributes": {"stroke": "black", "stroke-width": "0.5"} }, "labels": { "type": "lolimit", "dx": 18, "dy": 14, "conversions": { "32": "> 32" } }, "attributes": { "transform": "translate(-7 0)", "id": "windlegend", "class": "Label" }, "layers": [ { "tag": "text", "cdata": "m/s", "attributes": { "x": 28, "y": 12, "class": "Units" } } ] } ] } ] }

The table below contains a list of attributes that can be defined for the legend layer in addition to the common layer attributes.

LegendLayer 

TimeLayer

The time layer can be used in order to add the date and time information into the view.

The table below shows a simple example on the usage of the time layer.

Product configuration file

Produced image layer

{ // *** Product "title": "MyTimeLayer", "projection" : { "crs": "EPSG:3067", "bboxcrs": "WGS84", "xsize": 320, "ysize": 384, "x1": 11.2, "x2": 31.5, "y1": 53.2, "y2": 66.5 }, "views": [ { // *** View 1 "layers": [ { // *** Layer 1 "layer_type" : "time", "timestamp" : "origintime", "timezone" : "UTC", "format" : "%d.%m.%Y/%H:%M:%S", "x" : 140, "y" : 120, "attributes": { "text-anchor": "middle", "font-size": 18 } } ] } ] }

The table below contains a list of attributes that can be defined for the time layer in addition to the common layer attributes.

TimeLayer 

Both timestamp and format may be arrays, in which case their lengths should match. The formatted strings will be concatenated to the prefix and the suffix will be appended to the result. This feature can be used to print strings such as origintime + leadtime, starttime - endtime etc.

Times and time durations are formatted according to Boost.Date_time time formatter flag specifications.

TagLayer

The tag layer can be used to add different kinds of SVG elements such as lines, rectangles, circles, text, etc. in the view.

The table below shows a simple example on the usage of the tag layer.

Product configuration file	Produced image layer
{ // *** Product "title": "MyTagDemo", "width": 500, "height": 500, "views": [ { // *** View 1 "attributes": { "id": "view1" }, "layers": [ { // *** Layer 1: Yellow box with black borders "layer_type" : "tag", "tag" : "rect", "attributes" : { "x" : 150, "y" : 150, "width" : 200, "height" : 200, "fill" : "yellow", "stroke" : "black" } }, { // *** Layer 2 : Hello world text "layer_type" : "tag", "tag" : "text", "cdata" : "Hello world", "attributes" : { "x" : 250, "y" : 250, "font-size" : 18, "text-anchor" : "middle" } } ] } ] }
	Produced SVG file
	<svg width="500" height="500" xmlns="http://www.w3.org/2000/svg"     xmlns:xlink="http://www.w3.org/1999/xlink"> <title>MyTagDemo</title> <defs>    <style type="text/css"<>![CDATA[ ]]></style> </defs> <g> <g id="view1"> <rect fill="yellow" height="200" style="stroke:black" width="200" x="150" y="150"/> <text font-size="18" style="text-anchor:middle" x="250" y="250">Hello world</text> </g> </g> </svg>

The table below contains a list of attributes that can be defined for the tag layer in addition to the common layer attributes.

TagLayer 

WKTLayer

The WKT layer can be used insert an arbitrary geometry into the image in the Well Known Text format.

The table below shows a simple example on the usage of the WKT layer.

{
    "title": "WKT data",

    "projection":
    {
        "xsize": 500,
        "ysize": 500,
        "crs": "EPSG:3035",
        "bboxcrs": "WGS84",
        "cx": 25,
        "cy": 60,
        "resolution": 10
    },
    "views": [
        {
            "qid": "v1",
            "layers": [
                {
                    "qid": "mymap",
                    "layer_type": "map",
                    "map":
                    {
                        "lines": true,
                        "schema": "natural_earth",
                        "minarea": 50,
                        "table": "admin_0_countries"
                    },
                    "attributes":
                    {
                        "id": "europe",
                        "stroke": "#333",
                        "stroke-width": "0.5px",
                        "fill": "none"
                    }
                },
                {
                    "layer_type": "wkt",
                    "qid": "test1",
                    // non segmented box around Finland
                    "wkt": "POLYGON((30 60, 30 70, 20 70, 20 60, 30 60))",
                    "attributes":
                    {
                        "fill": "none",
                        "stroke": "black",
                        "stroke-width": 1
                    }
                },
                {
                    "layer_type": "wkt",
                    "qid": "test2",
                    // a bit bigger box with segmentation to 100 km resolution
                    "wkt": "POLYGON((40 50, 40 75, 10 75, 10 50, 40 50))",
                    "resolution": 100,
                    "attributes":
                    {
                        "fill": "none",
                        "stroke": "red",
                        "stroke-width": 1
                    }
                },
                {
                    "layer_type": "wkt",
                    "qid": "test3",
                    // biggest box with segmentation to 20 pixel resolution
                    "wkt": "POLYGON((50 40, 50 80, 0 80, 0 40, 50 40))",
                    "relativeresolution": 20,
                    "attributes":
                    {
                        "fill": "none",
                        "stroke": "green",
                        "stroke-width": 1
                    }
                }
            ]
        }
    ]
}

The table below contains a list of attributes that can be defined for the WKT layer in addition to the common layer attributes.

WKTLayer 

By default the WKT is not segmented into smaller linesegments. However, if the CRS of the image is not geographic, long straight lines in the WKT will not curve as expected unless the WKT is segmented into multiple parts in a resolution suitable for the output image. In the example above the black WKT is not segmented at all, the red one is segmented to 100 km resolution, and the green one to 20 pixel resolution.

WeatherFrontsLayer

The fronts layer renders cold, warm, occluded, and stationary fronts as SVG paths decorated with meteorological symbols (triangles and semi-circles) at even arc-length intervals. The symbols are rendered using a <textPath> element referencing a weather-font that maps specific characters to the standard front glyphs.

Two data sources are supported via the source field:

Front types

Symbols are rendered as inline SVG shapes (filled triangles and semicircles) — no external font is required. Uppercase glyph characters produce symbols on the left side of the directed path; lowercase on the right side. The layer places alternating symbols at even arc-length intervals using the spacing parameters below.

Compound glyphs ("CW", "Cw", etc.) place multiple shapes at the same position, used for occluded and stationary fronts.

WeatherFrontsLayer settings

For automatic front diagnosis from gridded data, use the TFP metaparameter with IsobandLayer or IsolineLayer (documented below). That produces Hewson's Thermal Front Parameter field directly as an isoband/isoline plot, which is how TFP is used in operational forecasting — as a diagnostic aid for a trained eye, not as an automatic detector.

fronts array (synthetic source)

Each element in the fronts array defines one front curve:

styles object

The styles object maps front type names to style overrides. Any omitted field keeps its default value.

Example 1 – synthetic fronts (cold, warm, occluded, stationary)

The product JSON that produced the image above:

{
    "title": "Weather fronts – synthetic example",
    "projection": {
        "xsize": 700, "ysize": 500,
        "crs": "EPSG:3857", "bboxcrs": "WGS84",
        "x1": -2, "y1": 47, "x2": 42, "y2": 67
    },
    "views": [{
        "qid": "v1",
        "layers": [
            { "layer_type": "background",
              "attributes": { "fill": "rgb(190,230,255)" } },
            { "qid": "land", "layer_type": "map",
              "map": { "schema": "natural_earth", "table": "admin_0_countries", "minarea": 50 },
              "attributes": { "fill": "rgb(220,220,210)", "stroke": "none" } },
            { "qid": "borders", "layer_type": "map",
              "map": { "lines": true, "schema": "natural_earth",
                       "table": "admin_0_countries", "minarea": 50 },
              "attributes": { "fill": "none", "stroke": "#555", "stroke-width": "0.5px" } },
            {
                "qid": "wf",
                "layer_type": "fronts",
                "css": "fronts/fronts.css",
                "front_source": "synthetic",
                "fronts": [
                    { "type": "cold", "side": "left",
                      "points": [[6,56.5],[8.5,55.5],[11,54.5],[14.5,54],[18,54.5],[21.5,55.5],[24.5,57],[27,59]] },
                    { "type": "warm", "side": "right",
                      "points": [[6,56.5],[5.5,58.5],[6,60.5],[7.5,62.5],[9,64],[11,65]] },
                    { "type": "occluded", "side": "left",
                      "points": [[6,56.5],[5,54.5],[4.5,52],[5,50],[7,48.5]] },
                    { "type": "stationary", "side": "left",
                      "points": [[27,59],[30,59.5],[33,60.5],[36,62],[38,63.5]] }
                ]
            }
        ]
    }]
}

The CSS file (fronts/fronts.css) defines the stroke colours for the front lines and the fill colour for the symbol shapes:

.coldfront       { fill: none; stroke: #0044cc; stroke-width: 2.5; }
.warmfront       { fill: none; stroke: #cc2200; stroke-width: 2.5; }
.occludedfront   { fill: none; stroke: #880088; stroke-width: 2.5; }
.stationaryfront { fill: none; stroke: #444444; stroke-width: 2.0; }
.trough          { fill: none; stroke: #996600; stroke-width: 1.5; stroke-dasharray: 6 3; }
.ridge           { fill: none; stroke: #006622; stroke-width: 1.5; stroke-dasharray: 6 3; }

.coldfrontglyph       { fill: #0044cc; stroke: none; }
.warmfrontglyph       { fill: #cc2200; stroke: none; }
.occludedfrontglyph   { fill: #880088; stroke: none; }
.stationaryfrontglyph { fill: #444444; stroke: none; }
.troughglyph          { display: none; }
.ridgeglyph           { display: none; }

HovmoellerLayer

A Hovmöller layer renders a two-dimensional time–space cross-section (or vertical cross-section) as a grid of coloured rectangles inside an ordinary SVG product. Unlike all other layers the coordinate axes are not a geographic map projection. Five slice geometries are supported:

The three time_* directions (true Hovmöller diagrams) iterate all time steps available in the querydata; the time query-string parameter is ignored for those. The two *_level directions are vertical cross-sections (not strictly Hovmöller diagrams) that render the single time step selected by the standard time= request parameter.

Each cell is coloured by matching the interpolated value against the first matching Isoband definition, using the same isoband JSON and CSS files as IsobandLayer.

The canvas pixel dimensions are taken from the product-level projection.xsize / projection.ysize. No geographic crs is required in the projection block.

HovmoellerLayer settings

Notes on level ordering and sparse data

For all *_level directions the levels are drawn with surface (high hPa) on the left / top by default (level_ascending=false). The data is commonly stored in ascending pressure order (300, 500 … 1000 hPa); the layer reverses this automatically so 1000 hPa appears first.

With only six pressure levels (as in the test data) the cells are wide and the diagram is more schematic than meteorologically detailed, but it clearly shows the vertical structure. Finer resolution requires model-level or high-density pressure-level querydata.

Example 1 – time × longitude (classic Hovmöller)

Shows how 500 hPa geopotential height ridges and troughs propagate eastward along 60°N over 10 days.

{
    "title": "Hovmoeller GeopHeight 500 hPa",
    "producer": "ecmwf_skandinavia_painepinta",
    "projection": { "xsize": 700, "ysize": 500 },
    "views": [{
        "layers": [{
            "layer_type": "hovmoeller",
            "parameter": "GeopHeight",
            "level": 500,
            "direction": "time_lon",
            "latitude": 60.0,
            "lon_min": 5.0,
            "lon_max": 35.0,
            "nx": 53,
            "isobands": "json:isobands/geoph500.json",
            "css": "isobands/geoph500.css"
        }]
    }]
}

Request: GET /dali?customer=…&product=hovmoeller_geoph500

Time increases downward (oldest at top). X axis: 5°E–35°E along 60°N. Colour scale: blue = trough / low GPH, red = ridge / high GPH.

Example 2 – time × latitude

Shows the meridional propagation of the 500 hPa ridge/trough pattern along 20°E.

{
    "title": "Hovmoeller GeopHeight 500 hPa – time vs latitude",
    "producer": "ecmwf_skandinavia_painepinta",
    "projection": { "xsize": 700, "ysize": 500 },
    "views": [{
        "layers": [{
            "layer_type": "hovmoeller",
            "parameter": "GeopHeight",
            "level": 500,
            "direction": "time_lat",
            "longitude": 20.0,
            "lat_min": 52.0,
            "lat_max": 70.0,
            "nx": 57,
            "isobands": "json:isobands/geoph500.json",
            "css": "isobands/geoph500.css"
        }]
    }]
}

Request: GET /dali?customer=…&product=hovmoeller_geoph500_time_lat

Time increases downward (oldest at top). X axis: 52°N–70°N along 20°E.

Example 3 – time × pressure level

Shows the vertical thermal evolution at a fixed location (60°N, 20°E) over the forecast period. All levels in the querydata are used automatically.

{
    "title": "Hovmoeller Temperature – time vs pressure level",
    "producer": "ecmwf_skandinavia_painepinta",
    "projection": { "xsize": 700, "ysize": 500 },
    "views": [{
        "layers": [{
            "layer_type": "hovmoeller",
            "parameter": "Temperature",
            "direction": "time_level",
            "latitude": 60.0,
            "longitude": 20.0,
            "isobands": "json:isobands/temperature_levels.json",
            "css": "isobands/temperature_levels.css"
        }]
    }]
}

Request: GET /dali?customer=…&product=hovmoeller_temperature_time_level

Time increases downward (oldest at top). X axis: pressure levels from surface (1000 hPa, left) to upper troposphere (300 hPa, right). Colour scale: red = warm (surface, low levels), blue = cold (upper troposphere).

GraticuleLayer

The graticule layer is used to draw a latitude-longitude grid.

A sample configuration from the tests (graticule_num_cross):

{
    "title": "Graticule demo",
    "producer": "kap",
    "language": "fi",
    "projection":
    {
        "crs": "data",
        "xsize": 500,
        "ysize": 500
    },
    "views":
    [
        {
            "qid": "v1",
            "layers":
            [
                {
                    "qid": "l1",
                    "layer_type": "map",
                    "map":
                    {
                        "schema": "natural_earth",
                        "table": "admin_0_countries",
                        "minarea": 100
                    },
                    "attributes":
                    {
                        "id": "europe_country_lines",
                        "fill": "none",
                        "stroke": "#222",
                        "stroke-width": "1px"
                    }
                },
                {
                    "qid": "l2",
                    "layer_type": "graticule",
                    "attributes":
                    {
                        "font-family": "Roboto",
                        "font-size": 10,
                        "text-anchor": "middle"
                    },
                    "graticules":
                    [
                        {
                            "layout": "grid",
                            "step": 1,
                            "except": 10,
                            "attributes":
                            {
                                "fill": "none",
                                "stroke": "#888",
                                "stroke-width": "0.2px"
                            }
                        },
                        {
                            "layout": "grid",
                            "step": 10,
                            "attributes":
                            {
                                "fill": "none",
                                "stroke": "#000",
                                "stroke-width": "0.5px"
                            },
                            "labels":
                            {
                                "layout": "cross",
                                "dy": 5,
                                "attributes":
                                {
                                    "fill": "black"
                                },
                                "textattributes":
                                {
                                    "filter": "url(#rectbackground?border=black&background=white&borderwidth=1)"
                                }
                            }
                        }
                    ]
                }
            ]
        }
    ]
}

The generated image is:

GraticuleLayer settings

Graticule settings

GraticuleLabels

CircleLayer

The circle layer is typically used to draw circles of specific radius around airports to indicate a specific area of interest.

A sample configuration from the plugin tests:

{
    "title": "Circles",

    "projection":
    {
        "xsize": 500,
        "ysize": 500,
        "crs": "EPSG:3035",
        "bboxcrs": "WGS84",
        "cx": 25,
        "cy": 60,
        "resolution": 1
    },
    
    "views": [
        {
            "qid": "v1",
            "layers": [
                {
                    "qid": "mymap",
                    "layer_type": "map",
                    "map":
                    {
                        "lines": true,
                        "schema": "natural_earth",
                        "minarea": 50,
                        "table": "admin_0_countries"
                    },
                    "attributes":
                    {
                        "id": "europe",
                        "stroke": "#333",
                        "stroke-width": "0.5px",
                        "fill": "none"
                    }
                },
                {
                    "layer_type": "circle",
                    "qid": "c",
                    "places":
                    [
                        "Helsinki",
                        "Tampere",
                        "Turku"
                    ],
                    "circles":
                    [
                        {
                            "radius": 20,
                            "attributes":
                            {
                                "stroke": "black",
                                "stroke-width": 1.5
                            }
                        },
                        {
                            "radius": 50,
                            "attributes":
                            {
                                "stroke": "black",
                                "stroke-width": 0.5
                            }
                        }
                    ],
                    "attributes":
                    {
                        "fill": "none"
                    }
                }
            ]
        }
    ]
}

The image generated from the configuration file:

CircleLayer settings

Circle settings

CircleLabels settings

TranslationLayer

The translation layer can be used to create products that support multiple languages. When a product is requested we can use "language" parameter to define which language to use. In this case the "language" parameter overrides the value of the "language" attribute in the product file.

The table below shows a simple example on the usage of the translation layer.

Product configuration file	Produced image layer
{ // *** Product "title": "MyTranslationDemo ", "language": "en", "projection": { "crs": "data", "xsize": 500, "ysize": 500 }, "attributes": { "filter": "url(#shadow)" }, "views": [ { "qid": "v1", "attributes": { "id": "view1" }, "layers": [ { "layer_type": "translation", "translations": { "en": "Hello World!", "fi": "Moro maailma!" }, "attributes": { "x": "250", "y": "250", "font-family": "Verdana", "font-weight": "bold", "font-size": "55", "fill": "yellow", "stroke": "black", "text-anchor": "middle", "filter": "url(#shadow)" } } ] } ] }

The table below contains a list of attributes that can be defined for the translation layer in addition to the common layer attributes.

TranslationLayer 

WindRoseLayer

The windrose layer can be used to add "wind roses" into the view. A wind rose shows the average wind speed for different directions over the given time interval.

The table below shows a simple example on the usage of the windrose layer.

Product configuration file

Produced image layer

{ "projection": ..., "defs": ..., "views": [ { "layers": [ { "layer_type": "windrose", "timezone": "UTC", "starttimeoffset": -12, "endtimeoffset": 12, "css": "wind/windrose.css", "windrose": { "minpercentage": 3, "radius": 30, "sectors": 8, "symbol": "windrose", "attributes": { "class": "WindRose" }, "connector": { "startoffset": 2, "endoffset": 30, "attributes": { class": "RoseConnector" } }, "parameter": "max_t(WindSpeed)", "limits": [ { "hilimit": 8,"attributes": { "class": "LightWind" } }, { "lolimit": 8, "hilimit": 14, "attributes": { "class": "ModerateWind" } }, { "lolimit": 14, "attributes": { "class": "HeavyWind" } } ] }, "observations": [ { "parameter": "mean_t(T)", "label": { "dx": 25, "dy": 16, "suffix": " °C" }, "attributes": { class": "RoseTemperature"} }, { "parameter": "mean_t(ws_10min)", "label": { "dx": 25, "dy": 3, "suffix": " m/s" }, "attributes": { "class": "RoseMeanWind"} }, { "parameter": "max_t(ws_10min)", "label": { "dx": 25, "dy": -10, "suffix": " m/s" }, "attributes": { "class": "RoseMaxWind"} } ], "stations": [ { "fmisid": 100908, "longitude": 23, "latitude": 61, "symbol": "station", "attributes": { "class": "StationMarker"}, "title": { "text": "Utö, "dx": -10, "dy": -26, "attributes": { "class": "StationName" } } }, { "fmisid": 101673, "longitude": 25.3, "latitude": 63.8, "symbol": "station", "attributes": { "class": "StationMarker" }, "title": { "text": "Ulkokalla", "dx": -20, "dy": -26, "attributes": { "class": "StationName" } } } ] } ] } ] }

The table below contains a list of attributes that can be defined for the windrose layer in addition to the common layer attributes.

WindRoseLayer 

OSMLayer

The OSM layer renders OpenStreetMap data loaded into PostGIS via osm2pgsql. It supports polygon features (landuse, water, buildings), linear features (roads, coastlines, administrative boundaries) and place-name labels. Each layer response carries an HTTP ETag derived from the OSM data age, enabling efficient HTTP caching. The OGC API – Tiles endpoint also supports Mapbox Vector Tile (MVT/PBF) output via the addMVTLayer mechanism.

Data setup and scale guidance

OSM data is not bundled; it must be downloaded and imported separately. The appropriate data source depends heavily on the target map scale:

Note: A simplified OSM planet extract is NOT a good substitute for Natural Earth at global scales (> 5 km/px). Its generalisation is inconsistent and file sizes are large for the quality achieved. Use Natural Earth (via MapLayer) for global/continental backgrounds and reserve OSM PostGIS for regional or local detail layers.

Import command using osm2pgsql:

osm2pgsql -d smartmet -U smartmet \
  --schema osm_scandinavia \
  --middle-schema osm_scandinavia \
  --output flex --style osm2pgsql-flex-config.lua \
  scandinavia-latest.osm.pbf

osm2pgsql creates the standard tables planet_osm_polygon, planet_osm_line, planet_osm_point and planet_osm_roads inside the configured schema.

ETag / caching

Configure a timestamp_file path. After each osm2pgsql import, touch that file:

touch /var/smartmet/osm/scandinavia.timestamp

The layer uses the file's modification time as the data version. All tile responses for the same viewport return HTTP 304 Not Modified until the file is touched again.

Multi-resolution strategy

Use MapLayer (Natural Earth) for global context and switch to OSMLayer for regional/local detail:

CSS styling and themes

The css field of each feature set specifies the stylesheet file to load. The attributes.class field selects which CSS class from that stylesheet applies to the SVG elements rendered for that feature set. This means one CSS theme file can style all feature types:

{ "css": "osm/osm-bright", "attributes": { "class": "water" } }

See the OSM style themes section below for ready-made CSS files.

Sample configuration

The example below combines Natural Earth (global background) with an OSM PostGIS layer (regional detail). Both feature sets use the osm-bright theme from osm/osm-bright.css.

{
  "layer_type": "group",
  "layers": [
    {
      "comment": "Global background from Natural Earth — no OSM import needed",
      "layer_type": "map",
      "minresolution": 2.0,
      "map": { "schema": "natural_earth", "table": "admin_0_countries", "minarea": 50 },
      "attributes": { "fill": "rgb(220,220,210)", "stroke": "none" }
    },
    {
      "comment": "Regional OSM detail — requires osm_scandinavia PostGIS schema",
      "layer_type": "osm",
      "maxresolution": 2.0,
      "timestamp_file": "/var/smartmet/osm/scandinavia.timestamp",
      "feature_sets": [
        {
          "pgname": "postgis",
          "schema": "osm_scandinavia",
          "table": "planet_osm_polygon",
          "where": "natural = 'water'",
          "mvt_layer_name": "water",
          "css": "osm/osm-bright",
          "attributes": { "class": "water" }
        },
        {
          "pgname": "postgis",
          "schema": "osm_scandinavia",
          "table": "planet_osm_polygon",
          "where": "landuse IN ('forest','wood')",
          "mvt_layer_name": "landuse_forest",
          "css": "osm/osm-bright",
          "attributes": { "class": "forest" }
        },
        {
          "pgname": "postgis",
          "schema": "osm_scandinavia",
          "table": "planet_osm_line",
          "where": "highway IN ('motorway','trunk','primary','secondary')",
          "lines": true,
          "mvt_layer_name": "roads_major",
          "css": "osm/osm-bright",
          "attributes": { "class": "primary" }
        },
        {
          "pgname": "postgis",
          "schema": "osm_scandinavia",
          "table": "planet_osm_point",
          "where": "place IN ('city','town','village')",
          "fieldnames": ["name", "place"],
          "labels": true,
          "mvt_layer_name": "place_labels",
          "css": "osm/osm-bright",
          "attributes": { "class": "place_label" }
        }
      ]
    }
  ]
}

Note: A rendered sample image will be added once OSM data has been imported. See the data setup instructions above.

OSMLayer supports two backends. The backend attribute selects which one is used; the required companion attributes differ between them.

PostGIS backend ("backend": "postgis", default): renders from osm2pgsql-imported PostGIS tables via the GIS engine. Requires feature_sets.

PMTiles backend ("backend": "pmtiles"): renders from a memory-mapped .pmtiles file managed by the OSM engine (engines/osm). Requires the OSM engine to be configured and loaded. For OGC Tiles / MVT requests the raw pre-encoded tile bytes are passed through directly — zero decoding or re-encoding. For WMS/SVG requests the tile is decoded via OGR. Requires source (the OSM engine source name).

The table below lists OSMLayer-specific attributes (in addition to the common layer attributes).

OSMLayer

OSMLayer FeatureSet

OSM style themes

Several ready-made CSS theme files are provided under layers/osm/. Each file defines CSS classes for common OSM feature types. Reference the same file in every feature set and set attributes.class to the appropriate feature class name.

Available themes (see file headers for full attribution):

Note: These CSS files define the visual style but cannot be tested until OSM data has been imported into PostGIS. Class names are identical across all themes so switching themes is a one-line change (edit the css field).

CSS class reference

All theme files define the following CSS classes:

PostGISLayer

The PostGIS layer can be used to create image layers based on data queried from the PostGIS database.

The table below shows a simple example on the usage of the PostGIS layer.

Product configuration file

Produced image layer

{ // *** Product "title": "Ice map", "projection": { "crs": "EPSG:2393", // YKJ "bboxcrs": "WGS84", "xsize": 800, "ysize": 800, "resolution": 1.75, "cx": 19, "cy": 60 }, "views": [ { // *** View 1 "attributes": { "id": "view1"}, "layers": [ { // *** Layer 1: Ice map "layer_type": "postgis", "lines": false, "pgname": "icemap", "schema": "icemap", "table": "seaice", "time_column": "publicationdate", "time_truncate": "day", "geometry_column": "geom", "css": "ice/icemap.css", "filters": "json:ice/icemap.json", "attributes": { "id": "iceareas" } }, { // *** Layer 2 : Country borders "layer_type": "map", "enable": "png", "map": { "lines": true, "schema": "natural_earth", "table": "europe_country_wgs84", "minarea": 20, "mindistance": 5 }, "attributes": { "id": "europe_country_line", "class": "Border" } } ] } ] }

The table below contains a list of attributes that can be defined for the PostGIS layer in addition to the common layer attributes.

PostGISLayer 

IceMapLayer

IceMapLayer inherits database-related functionality such as PostGISLayer definitions and filters from the PostGISLayer.

The table below shows a simple example on the usage of the PostGIS layer.

Product configuration file

Produced image layer

{ // *** Product "title": "Ice map", "projection": { "crs": "EPSG:2393", // YKJ "bboxcrs": "WGS84", "xsize": 800, "ysize": 800, "resolution": 1.75, "cx": 19, "cy": 60 }, "views": [ { "attributes": { "id": "view1"}, "layers": [ { "layer_type": "postgis", "pgname": "icemap", "schema": "icemap", "table": "seaice", "time_column": "publicationdate", "time_truncate": "day", "geometry_column": "geom", "css": "ice/icemap.css", "filters": "json:ice/icemap.json", "attributes": { "id": "iceareas" } }, { "qid": "l3-", "enable": "png", "layer_type": "map", "map": { "lines": true, "schema": "natural_earth", "table": "europe_country_wgs84", "minarea": 20, "mindistance": 5 }, "attributes": { "id": "europe_country_line", "class": "Border" } } ] } ] }

The table below contains a list of attributes that can be defined for the ice map layer in addition to the common layer attributes.

IceMapLayer 

FinnishRoadObservationLayer

FinnishRoadObservationLayer can be used to show weather conditions at road weather stations all over Finland.

The table below shows a simple example on the usage of FinnishRoadObservationLayer layer. Note! synop-font must be used to show the weather symbols correctly.

Product configuration file

Produced image layer

{ "title": "Road observations", "producer": "road", "timestep": 15, "language": "fi", "projection": { }, "views": [ { "qid": "v1", "attributes": { "id": "view1" }, "layers": [ { "qid": "finland", "layer_type": "map", "map": { "schema": "natural_earth", "table": "admin_0_countries", "where": "iso_a2 IN ('FI','AX')" }, "attributes": { "id": "finland_country", "fill": "rgb(255, 255, 204)" } }, { "qid": "finland-roads", "layer_type": "map", "map": { "schema": "natural_earth", "table": "europe_roads_eureffin", "where": "cntryname='Finland'", "lines": true }, "attributes": { "fill": "none", "stroke": "rgb(150,150,150)", "stroke-width": "0.6px" } }, { "tag": "g", "layers": [ { "qid": "l4", "layer_type": "map", "map": { "schema": "natural_earth", "table": "admin_0_countries", "minarea": 100 }, "attributes": { "id": "europe_country_lines", "fill": "none", "stroke": "#222", "stroke-width": "0.3px" } }, { "qid": "road_weather_stations_observations", "layer_type": "finnish_road_observation", "keyword": "road_weather_stations_master", "mindistance": 20, "attributes": { "font-family": "synop", "font-style": "normal", "font-weight": "normal", "font-size": 48 } } ] } ] } ] }

The table below contains a list of attributes that can be defined for finnish road observation layer.

FinnishRoadObservationLayer

Algorithm to deduce weather condition symbol

Step 1) Get the following parameters at requested timestep:

1. Mean air temperature (ILMA) of the observations from previous 24 hours
2. Precipitation type (SADE) of the nearest observation, maximum 20 minutes away
3. Precipitation form (RST) of the nearest observation, maximum 20 minutes away

Step 2) Get symbol for each station by using the following function, where 'r' is precipitation type and 'rform' is precipitation form:

if (r == 1)
    {
      if (rform == 9) return 51;         // drizzle, not freezing, intermittent, slight
      if (rform == 10) return 52;        // rain, not freezing, intermittent, slight
      if (rform == 11) return 53;        // intermittent fall of snowflakes, slight
      if (rform == 18) return 213;       // drizzle, freezing, slight
      if (rform == 19) return 223;       // rain, freezing, slight
    }
  if (r == 2)
    {
      if (rform == 9) return 209;        // drizzle, not freezing, intermittent, moderate
      if (rform == 10) return 219;       // rain, not freezing, intermittent, moderate
      if (rform == 11) return 229;       // intermittent fall of snowflakes, moderate
      if (rform == 18) return 214;       // drizzle, freezing, moderate or heavy
      if (rform == 19) return 224;       // rain, freezing, moderate or heavy
    }
  if (r == 3)
    {
      if (rform == 9) return 212;       // drizzle, not freezing, continous, heavy
      if (rform == 10) return 222;      // rain, not freezing, continous, heavy
      if (rform == 11) return 232;      // continous flall of snowflakes, heavy
      if (rform == 18) return 214;      // drizzle, freezing, moderate or heavy
      if (rform == 19) return 224;      // rain, freezing, moderate or heavy
    }
  if (rform == 13) return 225;          // rain or drizzle and snow, slight
  if (rform == 14) return 244;          // shower(s) of snow pellets or snow hail
  if (rform == 15) return 233;          // ice needles (with or without fog) 
  if (rform == 16) return 234;          // snow grains (with or without fog)
  if (rform == 17) return 236;          // ice pellets (sleet)

  // r 4,5,6 are redundant but re-check in case there is no match in the the cases above
  if (r == 4) return 53;        // intermittent fall of snowflakes, slight
  if (r == 5) return 229;       // intermittent fall of snowflakes, moderate
  if (r == 6) return 232;      // continous flall of snowflakes, heavy

Step 3) Get priority for each station by using the following function, where symbol is the symbol of the station and t2m is mean temperature of the station:

 if(t2m <= 0)
	{
	  // WINTER: t2m < 0
	  switch (symbol)
		{
		case 106:
		  return 0;
		  break;
		case 53:
		case 229:
		  return 1; 
		  break;
		case 232:
		case 233:
		case 234:
		case 236:
		case 244:
		  return 2; 
		  break;
		case 225:
		  return 5;
		  break;
		case 51:
		case 213:
		  return 6;
		  break;
		case 209:
		  return 7;
		  break;
		case 52:
		case 212:
		case 214:
		case 223:
		  return 8;
		  break;
		case 219:
		  return 9;
		  break;
		case 222:
		case 224:
		  return 10;
		  break;
		}

	}
  else if(t2m < 10)
	{
	  // SPRING OR AUTUMN: 0 > t2m < 10
	  switch (symbol)
		{
		case 106:
		  return 0;
		  break;
		case 51:
		case 52:
		case 53:
		case 213:
		case 223:
		case 225:
		  return 1;        // slight
		  break;
		case 209:
		case 219:
		case 229:
		case 233:
		case 234:
		case 236:
		case 244:
		  return 2;     // moderate
		  break;
		case 212:
		case 214:
		case 222:
		case 224:
		case 232:
		  return 4;      // heavy
		  break;
		}
	}
  else
	{
	  // SUMMER: t2m >= 10
	  switch (symbol)
		{
		case 51:
		case 52:
		case 106:
		  return 0;
		  break;
		case 209:
		case 219:
		  return 1;
		  break;
		case 212:
		case 222:
		  return 2;
		  break;
		case 213:
		  return 3;
		  break;
		case 214:
		  return 4;
		  break;
		case 225:
		  return 5;
		  break;
		case 53:
		case 223:
		  return 6;
		  break;
		case 224:
		case 229:
		  return 7;
		  break;
		case 232:
		  return 8;
		  break;
		case 233:
		case 234:
		case 236:
		case 244:
		  return 9;
		  break;
		}
	}

Step 4) Show stations on the map starting from the highest priority. If there already is a station nearby on the map (mindistance parameter), don't show the station.

PresentWeatherObservationLayer

PresentWeatherObservationLayer can be used to show present weather conditions at Automatic Weather Stations (AWS).

The table below shows a simple example on the usage of PresentWeatherObservationLayer layer. Note! synop-font must be used to show the weather symbols correctly.

Product configuration file

Produced image layer

{ "title": "Present weather observations", "producer": "opendata", "timestep": 10, "language": "fi", "projection": { }, "views": [ { "qid": "v1", "attributes": { "id": "view1" }, "layers": [ { "qid": "finland", "layer_type": "map", "map": { "schema": "natural_earth", "table": "admin_0_countries", "where": "iso_a2 IN ('FI','AX')" }, "attributes": { "id": "finland_country", "fill": "rgb(255, 255, 204)" } }, { "qid": "finland-roads", "layer_type": "map", "map": { "schema": "natural_earth", "table": "europe_roads_eureffin", "where": "cntryname='Finland'", "lines": true }, "attributes": { "fill": "none", "stroke": "rgb(150,150,150)", "stroke-width": "0.6px" } }, { "tag": "g", "layers": [ { "qid": "l4", "layer_type": "map", "map": { "schema": "natural_earth", "table": "admin_0_countries", "minarea": 100 }, "attributes": { "id": "europe_country_lines", "fill": "none", "stroke": "#222", "stroke-width": "0.3px" } }, { "qid": "wawa_observations", "layer_type": "present_weather_observation", "keyword": "synop_fi", "paramater": "WW_AWS", "mindistance": 20, "attributes": { "font-family": "synop", "font-style": "normal", "font-weight": "normal", "font-size": 48 } } ] } ] } ] }

The table below contains a list of attributes that can be defined for present weather observation layer.

PresentWeatherObservationLayer

Algorithm to deduce present weather symbol

Step 1) Get WaWa code (ww_aws) for the desired timestep

Step 2) Get symbol for each station by using the following get_symbol(float wawa-code) function:

float convert_possible_wawa_2_ww(float theValue)
{
    static const float wwCodeArray[100] =   
{0, 1, 2, 3, 4, 5, 0, 0, 0, 0,
 10, 0,13, 0, 0, 0, 0, 0,18, 0,
 28,21,20,21,22,24,29, 0, 0, 0,
 42,41,43,45,47,48, 0, 0, 0, 0,
 61,63,65,61,65,71,75,66,67, 0,
 50,51,53,55,56,57,57,58,59, 0,
 60,61,63,65,66,67,67,68,69, 0,
 70,71,73,75,79,79,79,77,78, 0,
 80,80,81,81,82,85,86,86, 0,89,
 92,17,93,96,17,97,99, 0, 0, 8};

    if(theValue >= 100 && theValue <= 199)
        return wwCodeArray[static_cast(theValue-100)];
    return theValue;
}

int get_symbol(float wawa)
{
  float value = convert_possible_wawa_2_ww(wawa);
  if(value != kFloatMissing && value > 3)
	{
	  if(value == 99)
		return 48; // synop fontin viimeinen arvo 255 osuu synop arvolle 98, onneksi myös 99 löytyy fontista, mutta sen sijainti on vain 48
	  else
		return (157 + value);
	}
  return 106; // Missing symbol 'Z'
}

Step 3) Get priority for each station by using the following function:

int get_symbol_priority(int symbol)
{
  switch (symbol)
	{
	case 106:
	  return 0;
	  break;
	case 170:
	case 171:
	case 172:
	case 173:
	  return 1;
	  break;
	case 162:
	case 163:
	case 164:
	case 165:
	case 167:
	case 168:
	case 169:
	case 174:
	case 177:
	case 178:
	case 179:
	case 180:
	case 181:
	case 182:
	case 183:
	case 184:
	case 185:
	case 186:
	case 198:
	case 207:
	case 208:
	case 213:
	case 215:
	case 217:
	case 218:
	case 227:
	case 235:
	case 242:
	case 244:
	case 246:
	case 248:
	case 249:
	case 250:
	case 251:
	  return 5;
	  break;
	case 187:
	case 188:
	case 189:
	case 193:
	case 195:
	case 197:
	case 199:
	case 200:
	case 209:
	case 210:
	case 219:
	case 220:
	case 225:
	case 228:
	case 229:
	case 233:
	case 234:
	case 236:
	case 237:
	case 240:
	  return 7;
	  break;
	case 161:
	case 175:
	case 211:
	case 216:
	case 221:
	case 223:
	case 230:
	case 231:
	case 238:
	case 252:
	case 253:
	  return 8;
	  break;
	case 201:
	case 202:
	case 203:
	case 204:
	case 205:
	case 206:
	case 212:
	case 239:
	case 241:
	case 243:
	case 245:
	case 247:
	  return 9;
	  break;
	case 166:
	case 176:
	case 190:
	case 191:
	case 192:
	case 194:
	case 196:
	case 214:
	case 222:
	case 224:
	case 226:
	case 232:
	case 254:
	case 255:
	case 48:
	  return 10;
	  break;
	}
  
  return 0;
}

MetarLayer

MetarLayer renders METAR aviation weather observations as standard meteorological station plots, one plot per airport. It queries raw TAC METAR (or SPECI) messages from the AVI engine and decodes them directly, so no pre-processing pipeline is required.

Each station plot can include:

• Wind barb — direction and speed in knots with standard meteorological barb notation
• Temperature / dew point — displayed in METAR convention (e.g. 03 / M02)
• Visibility — in metres, capped at 9999
• Present weather — raw TAC tokens (e.g. -RA, TSRA, +SN)
• Sky condition — cloud layers as amount+base (e.g. BKN025) or CAVOK/SKC
• QNH pressure — in hPa
• Wind gust — in knots when reported
• Aviation status box — colour-coded LIFR / IFR / MVFR / VFR category

Requires: The AVI engine (engines/avi) must be configured and loaded. MetarLayer is compiled out when WITHOUT_AVI is defined.

Aviation flight rule categories

The status box colour is derived from ceiling and visibility:

Sample configuration

{
  "qid": "metar_obs",
  "layer_type": "metar",
  "message_type": "METAR",
  "exclude_specis": true,
  "font_size": 10,
  "plot_size": 60,
  "mindistance": 50,
  "show_temperature": true,
  "show_dewpoint": true,
  "show_visibility": true,
  "show_wind": true,
  "show_pressure": true,
  "show_gust": true,
  "show_weather": true,
  "show_sky_info": true,
  "show_status": true,
  "attributes": { "id": "metar_layer" }
}

To restrict the plot to specific airports or countries:

{
  "layer_type": "metar",
  "icaos": ["EFHK", "ESSA", "EKCH"],
  "countries": ["FI", "SE", "NO", "DK"]
}

MetarLayer

Structure definitions

The product, view and layer definitions contain several attributes of type structure. This section defines attributes used in these structures.

Attribute structure

The Attributes structure is used to define attributes for the current Scalable Vector Graphics (SVG) element. This structure has quite many elements such as Product, View, Layer, etc. In this way we can define the drawing colors or the line widths that are used when the related SVG element is created.

The Attribute definitions are just plain mappings from strings to strings, i.e.. the attribute names and values are directly copied into the related XML element in the SVG file.

Using an attribute name or a value that is not in the the SVG specification may result in errors in the SVG file created.

The Attributes structure can contain one or several attribute definitions. For example:

	"attributes":
	{
   		"stroke": "black",
   		"stroke-width": "0.1"
	}

If the attribute value is a number, it can be given without the quotation marks. For example:

	"attributes":
	{
    		"stroke": "black",
    		"stroke-width": 0.1
	}

However, it should be noted that the number will then also be printed as a number into the SVG properties. In this particular case it would be wiser to use the string form, since the number 0.1 is not exactly an IEEE-754 number, and we actually get something a bit different in the output. Note that the integers in general are safe to be used without quotes.

AttributeSelection structure

Sometimes there is a need to use different SVG attributes and symbols according to field values that are used for the image drawing. For example, if there is sunny weather in location X and rainy weather in location Y, we probably want to use different weather symbols and SVG attributes for these locations in our weather map.

The AttributeSelection structure encapsulates an Attributes structure, a symbol and its usage condition in the same structure. The usage condition defines when the symbol and the attributes can be used. There is usually one AttributeSelection structure available for each condition. For example, if we have a data field that can have five different values then we probably have the AttributeSelection structure for each of these values.

The table below contains a list of attributes that can be defined in the AttributeSelection structure.

AttributeSelection 

EXAMPLE: Selecting a precipitation symbol according to a value:

	[
       		 {
            		"value": 0,
            		"symbol": "drizzle"
        	},
        	{
            		"value": 1,
            		"symbol": "rain"
        	},
        	...
        	{
            		"value": 6,
            		"symbol": "hail"
        	}
	]

EXAMPLE: Selecting a weather symbols and attributes:

	[
        	{
            		"value": 1,
            		"symbol": "sunny",
            		"attributes":
            		{
             			"class": "Sunny"
            		}
      		},
     		{
            		"value": 2,
            		"symbol": "partly_cloudy",
            		"attributes":
            		{
             			"class": "PartlyCloudy"
            		}
      		},
       	 ...
	]

EXAMPLE: Selecting attributes according to a value range:

	[
        	{
            		"lolimit": 3,
            		"hilimit": 5,
            		"attributes":
            		{
             			"class": "ModerateWindArrow_3_5"
            		}
        	},
      		{
 	     		"lolimit": 5,
            		"hilimit": 7,
            		"attributes":
            		{
             			"class": "ModerateWindArrow_5_7"	
            		}
        	},
      		{
            		"lolimit": 7,
            		"hilimit": 10,
            		"attributes":
            		{
             			"class": "FreshWindArrow_7_10"
           		}
      		},
        	...
	]

Projection structure

The Projection structure can be used to define a projection for a product, views or layers. The "projection" attribute is one of the shared attributes that is inherited from top to down in the product hierarchy. So, if the "projection" attribute is defined on the product level then all the views and the layers are using it, unless they do not override the value of this attribute.

The table below contains a list of attributes that can be defined in the Projection structure.

Projection

The bounding box of the projection can be defined in the following ways:

1. Bounding box with corners A bounding box is defined using the corner points and it should consist of "x1", "y1", "x2", "y2" and either "xsize" or "ysize". If both "xsize" and "ysize" are given, the aspect of the image may become distorted.

2. Bounding box with a center point A bounding box is defined using a center coordinate and it should consist of "cx", "cy", "resolution" and both "xsize" and "ysize".

3. Bounding box from data If "crs" = "data" is given and the a bounding box coordinates are not given, the bounding of the data will be used. The size still has to be defined separately.

CRS definitions

OGR/GDAL supports numerous ways to define a spatial reference. Currently OGRSpatialReference::SetFromUserInput supports the following methods:

1. Well Known Text definition - passed on to importFromWkt().
2. "EPSG:n" - number passed on to importFromEPSG().
3. "EPSGA:n" - number passed on to importFromEPSGA().
4. "AUTO:proj_id,unit_id,lon0,lat0" - WMS auto projections.
5. "urn:ogc:def:crs:EPSG::n" - ogc urns
6. PROJ.4 definitions - passed on to importFromProj4().
7. Filename - file read for WKT, XML or PROJ.4 definition.
8. Well known name accepted by SetWellKnownGeogCS(), such as NAD27, NAD83, WGS84 or WGS72.
9. WKT (directly or in a file) in ESRI format should be prefixed with ESRI:: to trigger an automatic morphFromESRI().
10. "IGNF:xxx" - "+init=IGNF:xxx" passed on to importFromProj4().

Defs structure

The Defs structure is used to define header information such as styles, symbols, paths not to be drawn directly, etc. for the generated SVG image.

The table below contains a list of attributes used in this structure.

Defs

Smoother structure

Two independent smoothers are available; only one runs per layer.

Savitzky-Golay (size/degree) is good at preserving local minima and maxima if at least degree 2 is used. Larger sizes with degree 2 tend to smooth data well while preserving extrema, higher degrees preserve original data better.

Trax grid smoother (method) is selected by giving a method. It supersedes size/degree when both are present. The methods are:

• box — separable box blur (normalized convolution). With passes >= 3 it approximates a Gaussian. Cheap and smooth, but it attenuates extrema like any low-pass filter. Cost is O(N) per pass independent of radius (running sums), so it is the cheapest way to smooth at any scale.
• median — per-window median. Removes spikes of either sign, keeps step edges sharp, and never invents a value that was not in the data (no overshoot). Preserves the value of features broader than the window. Uses an exact 2D window, so unlike box/morphology its cost grows with radius.
• morphology — grayscale opening/closing with a box element. Opening removes bright features smaller than the element while preserving the value of larger ones; closing does the same for dark features; openclose does both. Preserves the magnitude of broad extrema. Unlike box and Savitzky-Golay it never averages or interpolates: it takes the window minimum (erode) or maximum (dilate), so the output is the exact value of some input cell, and the structuring element is a flat, axis-aligned square (separable min/max along x then y, chosen because it runs in O(N) per pass independent of radius). The result is therefore terraced into square-cornered plateaus, which the contourer traces as visibly blocky, axis-aligned boundaries — a circular element would round them but would not be separable. Use morphology when you specifically want to delete small bright and/or dark speckles while preserving the exact magnitude of the larger features (e.g. cleaning isolated spurious pixels without flattening real peaks); prefer box or median when smooth-looking contours matter more than exact extremum values.

The radius/passes are in grid cells (index space), not projected distance.

Method gallery — the same temperature field and projection, smoothed by each method at a matched scale. The point of a smoother comparison is to judge how each method treats features of a given size, so the parameters here are deliberately tuned to remove roughly the same spatial scale rather than to a fixed radius value: at equal radius the rank/morphological filters remove much more than the polynomial Savitzky-Golay fit, which would make the comparison misleading. The Savitzky-Golay size 3 window (7×7) sets the reference scale, and box/median/morphology are dialed to match it (box radius 1, passes 3; median radius 2; morphology radius 2). At this matched scale the differences are about character, not amount:

• Savitzky-Golay keeps the most fine structure and the strongest extrema (a local polynomial fit), at the highest cost.
• box removes the same scale of detail but, being a linear low-pass, attenuates the cold pockets the most.
• median gives sharp, overshoot-free edges — every output value existed in the input — and preserves the value of features broader than the window.
• morphology (openclose) keeps the magnitude of the broad extrema but leaves visibly blocky, axis-aligned boundaries from its flat box structuring element.

Cost matters as much as character. The gallery above is tuned to equal smoothing quality, which flatters Savitzky-Golay — but it is the slowest filter, while box and morphology are O(N) per pass independent of radius and median sits in between (its cost grows with radius). On a busy server the right question is usually not "which preserves extrema best?" but "which is the cheapest filter that smooths well enough?" — and for plain speckle removal that is almost always box. The gallery below repeats the comparison at each method's minimal setting (Savitzky-Golay reduced to a 5×5 window, the others to a single 3×3-class pass): a single cheap box pass already removes the grid speckle nearly as well as the much more expensive Savitzky-Golay fit. Reach for Savitzky-Golay only when you genuinely need its exact extremum-height preservation and can afford the CPU; otherwise prefer box (general smoothing), median (spike/edge preservation) or morphology (speckle removal with magnitude preservation).

box also smooths correctly inside a missing-data footprint: the smoothing stays within the valid region and the missing-data boundary is preserved (the preserve_missing default).

The table below contains a list of attributes used in this structure.

Smoother

Sampling structure

Data to be contoured may be interpolated to another resolution. When used for temperature and topographic data is available, this may be used to provide higher apparent resolution by applying a lapse rate correction to the temperature. The desired resolution may be absolute or relative to the image resolution.

Heatmap structure

Heatmap settings for "flash" producer's data. Currently parameter's (e.g. peak power) values are not used when building heatmap (they could be used for weighting). Heatmap library (https://github.com/lucasb-eyer/heatmap) supports use of custom kernels for stamp generation. Currently three kernels are implemented.

The table below contains a list of attributes used in this structure.

Heatmap

Isoband structure

The table below contains a list of attributes used in the Isoband structure.

Isoband

If both lolimit and hilimit are omitted, the missing values isoband will be generated.

Intersection structure

The table below contains a list of attributes used in the Intersection structure.

Intersection

Note: Intersections work also for observation data. Instead of logical geometry operations the values are merely compared to the limits. For example, one may choose to render observed wind speed only when temperature is below zero.

Isoline structure

The table below contains a list of attributes used in the Isoline structure.

Isoline

Isofilter structure

Isolines and isobands can be smoothened by postprocessing the calculated polygons with a low pass filter.

Isofilter

Note that zooming into an image reduces the amount of smoothing since the set radius now covers a smaller area of the original data, and hence original details can be seen better.

The plain moving-average smoothers (average, linear, gaussian, tukey) always shrink: they pull every vertex towards the local average, so feature sizes collapse and a narrow isoband can fold onto itself. The taubin type alternates a shrinking pass (factor lambda) with an inflating pass (factor mu), so the overall shape and feature sizes (areas) are preserved while small details are still removed. This keeps isoband areas truer and reduces — but does not eliminate — smoothing-induced self-intersections, so it combines well with the validate setting.

The validate setting may be given as a boolean (true to enable with defaults) or as an object for finer control:

Isofilter validate

Validation only re-smooths when an actual radius/type is set, and for isolines it is effectively a no-op (a self-crossing line is still OGC-valid). It is most useful for isobands rendered with a wide gaussian radius.

LegendLabels structure

The table below contains a list of attributes used in the LegendLabels structure.

LegendLabels

LegendSymbols structure

The table below contains a list of attributes used in the LegendSymbols structure.

LegendSymbols

Text structure

The text structure is used to define translatable strings with optional styling attributes. The structure may for example be used to define fixed labels for isobands.

Text

Map structure

The table below contains a list of attributes used in the Map structure.

Map

Map amalgamation and simplification

The amalgamation_* and simplifier/tolerance options thin the polygons returned by PostGIS before they are clipped, projected, and rendered. They reduce SVG path length on dense coastlines, archipelagos, and high-resolution country borders, and let a single map dataset render cleanly across multiple zoom levels.

The pipeline applied by the GIS engine, in order:

1. Amalgamator (amalgamation_length / amalgamation_area): merges nearby polygons by triangulating the gaps between them with a constrained Delaunay triangulation. Gap triangles whose edges are all shorter than amalgamation_length are accepted as part of the merged outline; the shapetools amalgamate tool used the same idea. amalgamation_area filters polygons inside this step; setting only amalgamation_area filters small polygons without merging.
2. minarea: drops individual polygons whose area is below this km² threshold. Still useful after amalgamation to remove the small islands the amalgamator could not merge into a neighbour.
3. mindistance: runs GEOS SimplifyPreserveTopology with a kilometre tolerance. Independent of the new pixel-based simplifier and may be combined with it.
4. Simplifier (simplifier + tolerance): Visvalingam-Whyatt vertex removal applied per polygon. The underlying Fmi::GeometrySimplifier can also preserve shared boundaries when an upstream step has produced a topology with vertices shared between polygons (e.g. the contour engine's isoband/isoline output, or the output of the amalgamator above), but for typical PostGIS map data — where each feature is a separate polygon with its own copy of every vertex — the engine asks the simplifier to operate without cross-feature anchoring so that simplification is actually performed.

Amalgamation runs first so that the subsequent minarea and the new simplifier see the merged outline rather than each input island in isolation, and so that amalgamation_area does not pre-empt the more familiar minarea filter on un-merged polygons.

tolerance is specified in output pixels and converted to a CRS coordinate-unit² area threshold once per request using the active projection. Typical values are around 1–3 pixels: small enough that the silhouette is preserved at the chosen resolution, large enough that ~50–75 % of redundant vertices are removed.

Why Visvalingam-Whyatt only. Earlier versions also supported Douglas-Peucker ("douglas_peucker") but it was removed in favour of VW. DP keeps the points furthest from the chord between consecutive anchors, which on a smoothly-curving coastline tends to keep the tips of peninsulas while straight-cutting the bays between them — visibly spiky at any non-trivial tolerance. Worse, on closed rings without topology preservation DP needs synthetic anchors, which the implementation finds via an O(n²) all-pairs distance search per ring; on a single ~10 000-vertex coastline ring this alone takes 30+ seconds. VW is O(n log n), tracks the overall shape character better on natural features, and works equally well for the rare polygonal/man-made cases.

Choosing an algorithm

The four operations attack different problems and can be combined freely. A short comparison:

Rules of thumb:

• For an archipelago or a coastline with thousands of small islands, run the amalgamator first; the simplifier alone will leave you with thousands of separate triangles instead of fewer, recognisable outlines.
• minarea after amalgamation is still useful to trim the small islands that were too far from a neighbour to be merged.
• For amalgamator parameters (amalgamation_length, amalgamation_area) the units are CRS coordinate units (degrees in EPSG:4326, metres in projected CRS), not km. At 60° N, 1° lat ≈ 111 km and 1° lon ≈ 56 km — so amalgamation_length=0.05 ≈ 3 km and amalgamation_area=0.0005 ≈ 1.5 km².

The seven examples below are drawn from the regression suite (test/dali/customers/test/products/map_*.json) and double as reference outputs. All seven render the same Northern-Baltic view (lon 18°–27°, lat 59°–65°, 900×600 px) of the high-resolution gshhg.gshhs_h_l1 table (GSHHG-h L1 land polygons, ≈ 200 m vertex spacing, ~14 000 polygons in the bbox prefilter). They are directly comparable so that the visual effect of each option is easy to read. The four amalgamation rows (map_amalgamate, map_amalgamate_wide, map_amalgamate_extreme, map_amalgamate_pathological) form a deliberate calibration sequence — amalgamation_length 0.01 → 0.02 → 0.05 → 0.1 — showing how the silhouette degrades as the gap distance grows past a sensible value for the rendering pixel scale, all the way to "the algorithm still produces valid topology but the output is nonsensical."

MapStyles structure

Individual map features can be styled based on a forecast value assigned for the area. For example, one can colour regions based on the forecast warning level for the area.

The table below contains a list of attributes used in the MapStyles structure.

MapStyles

Note: Optional FeatureMapping attributes override common MapLayer attributes, and attributes based on the actual data value override both.

MapFeature structure

Feature mappings are used to make database shape names to region numbers to be picked from forecast data. Feature mappings are not needed if the database contains region numbers directly. However, feature mappings can also be used to style individual regions.

The table below contains a list of attributes used in the MapFeature structure.

MapFeature

Note: Optional FeatureMapping attributes override common MapLayer attributes, and attributes based on the actual data value override both.

Positions structure

The Positions structure can be used to define a list of positions which are needed in quite many layers. For example, in the NumberLayer this structure defines positions for the printed number, in the SymbolLayer it defines positions for the symbols and in the ArrowLayer it defines positions for the arrows.

The table below contains a list of attributes used in this structure.

Positions

Note: The direction is positive for wind. For currents one may use "rotate"=90 or a negative "directionoffset". If an extra rotation is desired, it is recommended to use a negative offset.

If the layout is not "data" and the producer refers to observations, the generated candidate locations will be snapped to the nearest stations if the "maxdistance" condition set for the layer is satisfied. This way one may for example place candidate points into a grid and get an evenly distributed sample of the full set of stations.

The margins can be used to generate point locations outside the image area. This is useful for example if the symbols to be placed at the locations can be expected to overflow to adjacent WMS tiles. xmargin and ymargin can be set simultaneously using the "margin" setting.

Label structure

The table below contains a list of attributes used in the Label structure.

Label

Note: signed prefixes are needed in aviation charts where negative temperatures are typically shown without a sign. In the exceptional case where positive numbers are actually needed, they are displayed using a plus sign or a "PS"-prefix.

LabelConfig structure

The LabelConfig structure is used by LocationLayer to place location name labels next to point symbols. See LabelConfig settings for the complete reference including algorithm-specific parameters and the classes population-override array.

The key fields are summarised here for quick reference:

LabelConfig (summary)

Location structure

The table below contains a list of attributes used in the Location structure.

Location

Observation structure

The table below contains a list of attributes used in the Observation structure.

Observation

Station structure

The table below contains a list of attributes used in the Station structure.

Station

Note that both longitude and latitude have to be specified in order to alter the location where a number or something else will be displayed instead of the station coordinates.

WindRose structure

The table below contains a list of attributes used in the WindRose structure.

WindRose

Connector structure

The table below contains a list of attributes used in the Connector structure.

Connector

Filters structure

The table below contains a list of attributes used in the Filter structure.

Filters

Using dynamically created grids

Introduction

A layer usually contains the "parameter" attribute definition, which refers to the grid data that is needed in order to draw the current layer. Typically the value of the "parameter" attribute is a parameter name that points to fixed grid data, which means that this data is pre-calculated. In this case the biggest drawback is that if we want to get grids that are calculated differently then we need a pre-calculation process that calculates these grids and stores them in such way that they can be accessed.

Luckily now there is a way to caculate new grids on the fly and use their data as they were fixed grids. The basic idea is that the "parameter" attibute can contain a function that defines how the new grid should be calculated. This feature is available only for producers that use grid-engine.

There are two different ways to create new grids:

1. We can create new grids that uses data from other grids that have the same timestamp.
2. We can create grids that uses data from multiple timesteps. For example, calculating max temperature values for a day.

Grids with the same timestamp

Here are some examples that calculate a new grid from other grids that have the same timestamp:

The new grid contains maximum values from 3 ensemble grids (1,3,5):

    "parameter" : "MAX{Temperature:MEPS:1093:6:0:3:1;Temperature:MEPS:1093:6:0:3:3;Temperature:MEPS:1093:6:0:3:5}"

The new grid contains average values counted from 14 ensemble grids (1-14):

    "parameter" : "AVG{Temperature:MEPS:1093:6:0:3:1-14}"

The new grid contains probability percentage that the values in 14 ensemble grids (1-14) are below zero (= in range -1000 .. 0):

   "parameter": "IN_PRCNT{-1000;0;Temperature:MEPS:1093:6:0:3:1-14}"

Grids calculated over multiple timesteps

The basic idea is that, we can have multiple timesteps before and after the requested time. The timestep size (in minutes) can be used in order to calculate timestamp for the requested data. The requested data is expressed in timestep index range (not actual time lengths). The index number 0 refers to the requested time, the first timestep before the requested time is refered with the index number -1, and the first timestep after the requested time is refered with the index number 1. If functions require additional parameters (like value range), these parameters are added after the timestep range and timestep size defintions.

Here are some examples:

The new grid contains maximum values from the previous 24 timesteps.Timestep size = 60 minutes, range of grid indexes = [-23 .. 0] counted from the requested time.

    "parameter" : "/MAX{Temperature;-23;0;60}"

The new grid contains probability percentage that the temperature drops below the zero (= is in range -1000..0) during the following 48 hours.

    "parameter": "/IN_PRCNT{Temperature;0;47;60;-1000;0}"

Functions

Dynamic grid caculation uses C++ or LUA functions for creating new grids. C++ functions are faster than LUA functions and that's why we try to implement most common functions with C++. At least the following functions are currently available for producing new grids:

    AVG		=> Calculate average/mean values.
    MAX		=> Calculate maximum values.
    MIN		=> Calculate minimum values.
    MUL		=> Multiplies grid values with a multiplyer. This can be used also for dividing grid values (i.e. multiplier = 1/divider).
    SUM		=> Add 1-N grids together. If there are additional numbers in the function then these numbers are added to each grid value.
    IN_PRCNT	=> Returns the probability percent that the value in the given grids is inside the given value range.
    OUT_PRCNT	=> Returns the probability percent that the value in the given grids is outside the given value range.

JSON references and includes

Product JSON files support four mechanisms for composing and reusing configuration fragments.

json: value references

Any JSON string value that starts with json: causes the corresponding file to be loaded and the string replaced with the parsed JSON content. Paths are resolved relative to the customer layers/ directory (e.g. <root>/customers/<customer>/layers/), or if the path starts with /, relative to the Dali root directory.

{
    "isobands": "json:isobands/temperature.json",
    "label":    "json:numbers/integers.json"
}

When a json: value appears as an element of an array, the loaded JSON replaces that element (useful for including complete layer definitions):

"layers": [
    "json:paths/legendmask.json",
    { "layer_type": "map", "..." }
]

ref: cross-references

Any string value of the form ref:<dotted.path> is replaced with the value found by following the dotted path in the current JSON document. The top-level refs object is a conventional place to collect reusable fragments:

{
    "refs": {
        "finland": {
            "schema": "natural_earth",
            "table":  "admin_0_countries",
            "where":  "iso_a2 IN ('FI','AX')"
        },
        "myprojection": "json:maps/finlandprojection.json"
    },
    "projection": "ref:refs.myprojection",
    "views": [{
        "layers": [{
            "layer_type": "isoband",
            "inside": "ref:refs.finland"
        }]
    }]
}

JSON Pointer ($ref) dereferencing

Standard JSON Pointer references of the form {"$ref": "#/path/to/value"} are resolved after json: and ref: substitution. This follows the JSON Reference / JSON Schema convention.

Processing pipeline

The product JSON goes through the following stages, which can be inspected individually by adding stage=<n> to the request:

Symbol substitutions via URI

SVG resources referenced via url(#name) — markers, fill patterns, filters, and gradients — can be parameterised by appending a query string to the fragment identifier:

url(#<symbol-name>?<param1>=<value1>&<param2>=<value2>)

The plugin loads the SVG resource file, substitutes every $(variableName=defaultValue) placeholder with the supplied value (or the default if the parameter is absent), and injects the result into the SVG <defs> section.

Example — coloured spearhead marker:

In the JSON attributes:

"marker-end": "url(#spearhead?fill=#606060)"