Map Layers
There are multiple different possibilites to work with Map Layers in SAMO LIDS Browser module. Basically the definition of the layers is splited into two individual levels, background and foreground.
Basics
User can select multiple Layers from tree of layers in foreground at once, but only one layer of background at once. Main configuration of the layers is included in the map definition (samo-lids-browser.json in our example). Basically it can also be splitted into different configuration files. All possible layers can be used either in samo-lids-browser.json or in an individual *.json and its ID's are just referenced in the main configuration. Follwing structure is used as example:
dynamic-app
│
└───samo-demo\configuration
│
└───map
│
└───layers
| └───customLayers.json
| └───backdrops.json
└───samo-lids-browser.json
Single layer files (e.g. customLayers.json) corresponds to an array of objects, where each object is an individual layer definition with unique id.
Description of basic possibilites for layer configurations are in Dynamic-App Module catalog. Following some examples:
Setdefinition and categories
Setdefinitions are prepared in SAMO LIDS Explorer as templates, categories are prepared in model.xml.
{"id": "setdefinition_201105021258"}, {"id": "cat_lighting"}
Title is overtaken from the server.
{"id": "setdefinition_201105021258_ele-routes"}
{
"id": "setdefinition_7247984945283072",
"type": "lids-map-layer-wms",
"singleTile": true
}
To have the possibility to add a setdefinition as WMS Layer, it has to be defined in map-service.xml in root context.
Heatmap and Clustering
{
"id": "heatMap",
"type": "lids-map-layer-heatmap",
"title": "heatMap",
"sourceLayer": {
"id": "setdefinition_2011050282"
}
}
{
"id": "cluster",
"type": "lids-map-layer-cluster",
"title": "cluster layer",
"distance": "45",
"condition": "click",
"labelStyle": {
"Text": {
"symbolHeight": "12",
"offsetX": 0,
"offsetY": 0,
"strokeColor": "rgba(0,0,0,0.4)",
"fillColor": "#fff",
"strokeWidth": 4
}
},
"clusterStyle": {
"Circle": {
"fillColor": "rgba(96, 198, 253, 0.5)",
"strokeColor": "rgb(2, 136, 209)",
"strokeWidth": 2
}
},
"sourceLayer": {
"id": "setdefinition_2011050282"
}
}
Backdrops
{ "id": "bd_03", "title":"City Map"}
WMS should be defined in map-service.xml root context (this step will be probably removed in the future)
title must be defined in configuration.
{
"id": "street-overlay",
"type": "lids-map-layer-wms",
"singleTile": true,
"url": "https://wms.example.com/?",
"wmsParams": {
"LAYERS": "topo-strassen"
}
}
{ "id": "tms_orthophoto_2014"}
To automatically configure TMS layer we have to use WMTS => define WMTS layers in root context.
{
"id": "bd_swisstopo_neu",
"title": "Landeskarte",
"type": "lids-map-layer-wmts",
"layerName": "topo-farbe",
"matrixSet": "2056_28",
"autoConfiguration": true,
"url": "https://wmts.example.com/EPSG/2056/1.0.0/WMTSCapabilities.xml"
}
Layer grouping
{
"id": "rs_folder",
"title": "Redlining + Sketch as folder",
"layers":[
{"id": "cat_5070000"},
{"id": "cat_5080000"}
]
}
{
"id": "rs_folder",
"type": "lids-map-layer-group",
"title": "Redlining + Sketch as folder",
"layers":[
{"id": "cat_5070000"},
{"id": "cat_5080000"}
]
}
Dynamic Feature API Layer
Definition of map layers can be also set without defining LIDS setdefinitions. This is mostly the case for project, which do not use LIDS Explorer. The big advantage is, the possibility to use templating for configuration of dynamic filters. There is an individual chapter about Feature API.
{
"id": "my-sketchings",
"title": "My Sketchings",
"type": "lids-map-layer-feature-api",
"request": {
"output": {
"graphics": {},
"properties": {},
"symbologyTokens": {}
},
"theme": "theme_id from thematization.xml",
"types": {
"ft_5081000": {
"filter": {
"type": "compare",
"operator": "equal",
"leftOperand": {
"type": "property",
"property": "createdBy"
},
"rightOperand": {
"type": "literal",
"value": "{user:#id}"
}
}
}
}
}
}
Layer properties
Basic layer properties
All layers can be extended with optional properties, usually with title and an icon from any iconset (internal).
{
"id": "bd_wms_BSA_BezPunkte",
"title": "Bezugspunkte",
"icon": "samo-icons-maps:layer-external"
}
For folders we can also use an icon of opened folder:
"iconOpened": "samo-icons:folder-open-filled"
For backdrop Layers there can be a preview picture instead of the icon:
"preview": "images/backdrops/landeskarte.png"
Additional layer properties
Following, there are examples of frequently used additional layer properties:
"visible": true
"minScale": 500
"maxScale": 10000
"notSelectable": true
"showPopupDetail": true /*requires entity & detail configuration)*/
"withGraphicTags": false /*don't display the graphicTags of all objects in the layer*/
"withSemantics": true /*loads the semantics of the data as well. Slower. Needed only to display attributes as label different than featureInfo*/
"disableShowSemantics": true /*layer context action 'Show in table" will be not available*/
Using additional layer properties we can even configure our own layer context navigation actions. User can then click on layer and display some page with additional information about the data, or the possibility to download them. This is used especially in Portal solutions.
"actions": [
{
"type": "uri-link",
"href": "pu-open-data#ispu-pu-stazeni",
"openInNewTab": true,
"title": "Download data",
"icon": "samo-icons-file:file-download"
},
{
"type": "uri-link",
"href": "pu-open-data#ispu-pu-popis",
"openInNewTab": true,
"title": "Data description",
"icon": "samo-icons:info"
}
]
Overriding layer properties
In case there are multiple browser contexts in one SAMO Application, it is often the case, that layers are defined in single configuration files and afterwards used multiple times in different browser contexts (Agendas' Map Viewers). Single layer properties can be overriden, or extended for specific browser context (in the corresponding browser context configuration files). When overriding layer, we must define overrideLayers object, which contains key-value pairs of overriden layers. Keys correspond to the unique layer ids.
"overrideLayers": {
"ortophoto": {
"visible": true
}
}
If you are overriding layers visibility, the best practice is to define all layers hidden ("visible": false) by default and make them visible ("visible": true) only when needed in the given browser context.
Legends
Application loads legends based on currently visible (turned on) layers. These can be either displayed by user, or are included in the print outputs. Currently all map layers must be created manually as pictures. We use for example this Free online SVG editor Vecta.io, which enables online collaboration. We export individual legends or legend items to .png files with resolution 300 dpi.
The best practice is to have the legend configuration in default browser context (samo-lids-browser.json in our case). Legend configuration only consists of correct reference to the picture.
"legends": {
"wasser_werkplan": {
"src": "resource:legends/Wasser_WP.png"
},
"elektro_werkplan": {
"src": "resource:legends/Elektro_WP.png"
},
"elektro_auswertung_trassen": {
"src": "resource:legends/Elektro_Trassen.png"
}
}
Individual layers can reference multiple legends, so it is possible to have a separate picture of legend category title and separate pictures of all categories with descriptions. Thus in the application, only categories, that are currently visible in the map are present in the displayed (printed) legend.
{
"id": "setdefinition_7247984945283072"
"legends": [
"elektro_werkplan_title",
"elektro_werkplan"
]
}
Referencing
If the layer is defined in any additional configuration file, it has to be referenced into main configuration (browser context). This is mainly done for the background and for featureAPI Layers.
"backdropLayers": [
"orthofoto",
"orto-plus-names",
"landeskarte_farbe",
"backdrop_av",
"geodiensteWMS"
]
"layers": [
"my-sketchings",
"rs_folder",
"setdefinition_7247984945283072"
]
Layers and folder can be both used. The order of layers in the array corresponds to the order in the application Layer panel.