Various improvements to the Grafana Worldmap Panel have been made in order to integrate important contributions from the community and by adding some other features from our pen.
The following posts will give you an idea about how Grafana Map Panel was improved around April/May/June 2019 on behalf of The Hiveeyes Project.
Beginning 2020, the development continues on behalf of the Panodata Initiative.
table+json(p)” Location DataThe “Location Data” options “table+json” and “table+jsonp” unlock the ability to use a metric source formatted as table as the primary source for location data information while looking up the corresponding label from a JSON document, extending what the plain “table” option already does by combining existing processing/transformation paths in a convenient manner.
If you prefer to read code, the corresponding software test for this feature might be good place to start.
/*
* Hybrid "table+json(p)" Location Data
*
* We are testing the "table+json" and "table+jsonp" location data
* sources here. They are used when basic location information is
* coming from table data but humanized labels are resolved from a
* JSON/JSONP data source by appropriate field name mapping.
*/
This section gives a detailed overview over appropriate configuration of 1. the data source metric, 2. the JSON document for resolving corresponding humanized labels and 3. the respective Grafana Worldmap Panel settings to successfully map all fields and resources.
The primary location data source is determined through the metric we are querying from. Specifically, this is an InfluxDB data source which is formatted as “Table”. The response yields the fields/tags “station_id”, “geohash” and “metric”.
SELECT last("P1") AS "metric"
FROM "ldi_readings"
WHERE ("station_id" =~ /^$ldi_station_id$/) AND $timeFilter
GROUP BY "geohash", "station_id"
{
"results": [
{
"series": [
{
"columns": [
"time",
"metric"
],
"name": "ldi_readings",
"tags": {
"geohash": "u0wt1tdd0x1d",
"station_id": "19"
},
"values": [
[
1555738566000,
5999.12
]
]
},
{
"columns": [
"time",
"metric"
],
"name": "ldi_readings",
"tags": {
"geohash": "u0wt6pv2qqhz",
"station_id": "28"
},
"values": [
[
1555738438000,
9.13
]
]
}
],
"statement_id": 0
}
]
}
The effective label is resolved by looking it up from a corresponding JSON document acquired and processed exactly like the “json(p) endpoint” options
which looks like
[
{
"key": "19",
"name": "Alte Dorfstra\u00dfe, Birkach, Stuttgart, Baden-W\u00fcrttemberg, DE"
},
{
"key": "28",
"name": "Ulmer Stra\u00dfe, Wangen, Stuttgart, Baden-W\u00fcrttemberg, DE"
},
]
The value from the table field designated by “Location Name Field” (here “station_id”, see response above)
will be used to run a lookup against the “key” field of the JSON document as depicted above. If there’s a match, the value associated with the corresponding name will be returned.
We are using this to display synthesized address information on a map populated with data coming from luftdatenpumpe through InfluxDB and PostGIS data sources, see also LDI data plane v2.
In one of our data planes, we are feeding data from the luftdaten.info project into an InfluxDB database using luftdatenpumpe.
As the data from InfluxDB is designated by "FORMAT AS Table" into the Worldmap Panel, we couldn’t find a way to acquire the Location Name from a JSON/JSONP data source as it is possible with the "FORMAT AS Time series" variant already.
This PR accounts for that. When choosing to load location data using the new mapping options "table+json" or "table+jsonp", it is possible to load location information from JSON. The value of the data field designated by the "Location Name Field" will be used as a key for looking up the appropriate record in the JSON dataset. If the lookup fails, the specific code path is backward compatible and should produce the same results as before by using the value of the "Location Name Field" itself.
By applying that to our installation, we have been able to display a long location name acquired from ldi-stations.json on the map overlay of LDI stations map without having to store the name inside the InfluxDB measurement table itself. We don’t even want to keep a short name there, the lookup is solely done by using a single location identifier, the numeric station_id:
As we are displaying a number of small-sized map widgets on dashboards like the weather.hiveeyes.org landing page or Vergleichende Stationsansicht: UBA ./. LDI korrigiert, we wanted to optimize different things on the display side.
All amendments can be conditionally configured through appropriate plugin settings, so they are completely optional and behave backward-compatible by not modifying the behavior for map panels already configured.
We are currently keeping the amendments to Worldmap in our develop branch.
Over the course of the next posts, we want to outline the changes and provide some background information about it.
When moving the mouse at the corners of the map, Leaflet starts panning around in order to display the popup without clipping it. In general, this is a good thing.
However, it turns out this isn’t possible on a small view area at all: It happens way too quick when navigating through a small map and just makes the user crazy.
We added the autoPanLabels option to accommodate for that, which defaults to true so it doesn’t change the default behavior.
The popup label content gets clipped on small maps.
We added the autoWidthLabels option to accommodate for that which defaults to true so it doesn’t change the default behavior. When set to false,
the popup layout looks more pleasant.
– Example: [Feinstaub PM10] Vergleich: Umweltbundesamt (UBA) vs. Korrektur luftdaten.info (LDI)
Both control elements (zoom control and attribution) cover too much space on small maps.
We added the showZoomControl and showAttribution options to accommodate for that. Both default to true so they don’t change the default behavior. When set to false ,
small map widgets look more pleasant to us.
// Hide zoom control and attribution.
$('.leaflet-control-zoom').hide();
$('.leaflet-control-attribution').hide();
The legend sometimes covers too much room on small maps.
So let’s just display it elsewhere on the dashboard, right?
Let’s define a Text-Box which should act as a container element.
In the panel settings, the output can be redirected to another DOM element by specifying a jQuery element-selector expression.
Cool! Can you please spend a <center>-tag, too? For the pleasantness!
In order to not encourage copyright-infringements, I suggest a read-only multi-line text-field with the correct attribution (probably prefixed with the panel’s title) in Hypertext (or Markdown), introduced with the words “In order to respect the copyright of many cool people, you should now add this attribution-text somewhere else on the dashboard:”, suddenly appearing after unchecking the “show attribution”-box.
.oO( or shall it automagically create a text-field panel with the attribution-text/html, like within the new legend-option? )
I second that. We will see how this would be implemented exactly, thanks for sharing your thoughts.
When using the Grafana light theme, popover labels are barely visible.
dtheb supplied a fix for that the other day. Thanks!
Daniel Lee already added the feature "stickyLabels": true for this. Thanks!
We know this feature is well-requested already.
Variant 1: Assign URL from panel settings.
Variant 2: Assign URL from database field.
There are two ways of attaching clickthrough-links to circles. Either assign the URL through the corresponding “Clickthrough URL” editor option or take the URL from a database field of the respective data point by using the “Link field” option. By running the outcome through Grafana’s variable interpolation machinery, both dashboard and data point variables will get interpolated at runtime into the strings typed in there as you can see from the first screenshot above.
All dashboard variables will get interpolated 1:1 while values coming from a data point will get prefixed by "__field_" to be able to tell them apart and avoid collisions.
Using the “Clickthrough Window” setting, the panel operator is able to control the designated target browsing context (formerly called “frame”), which is either a named window or one of the well known literal strings “_blank”, “_self”, “_parent” or “_top” with their respective semantics listed below. Using the named window variant, it is easily possible to support dual- and multiscreen-scenarios by just arranging multiple browser windows on different screens.
Currently, the clickthrough-links are attached to the respective circle. Injecting and attaching links into the popover label (see “Sticky labels”) is reserved for some future iteration on that.
| Value | Description |
|---|---|
| _self | Open the link in the current frame. This is the default behavior. |
| _blank | Open the linked document in a new tab or window, depending on browser configuration. |
| _parent | Open the link in the parent frame, otherwise resorting to _self. |
| _top | Open the link in the top-level frame, otherwise resorting to _self. |
| frame name | Open the link in the named frame. |
– https://wiki.selfhtml.org/wiki/Referenz:HTML/Attribute/target (sic!)
This is a simple implementation of a panel option being used to navigate to a new URL on click.
– https://github.com/hiveeyes/grafana-worldmap-panel/commit/09432e8672d94658273d56856d94e892467f183d
This adds the possibility to obtain the clickthrough-link from the database through the
linkFieldeditor option.
Add basic variable interpolation based on keys from
dataPoint.
Saying that, all metric values have been added to the dataPoint
beforehand by prefixing them with__field_to allow for setting
things likeclickthroughURL: /url/to/$__field_station_idif
there’s a field calledstation_idin the current datapoint.
Use the regular Grafana templating mechanism for interpolating variables into clickthrough links, thus interpolating dashboard and dataPoint variables now.
Shoutouts to James Nicholls and Leonhard Haas for sharing the contributions referenced above through #129 and #190. Thanks!
Apply Grafana-style variable interpolation to all panel settings.
This outlines various details about how the functionality for interpolating values into panel settings has been improved through variables originating from different kinds of sources.
As of now, the interpolation machinery honors the well known Grafana dashboard variables as well as request parameters (prefixed by "request_") and data point fields (prefixed by "__field_").
This enables the interpolation of dashboard variables into each of the panel control settings (source, commit).
An example would be to have a variable called “countrycode” which gets populated by a database query defined by an SQL statement.
SELECT
country_code AS __value,
country_name AS __text
FROM
stations
ORDER BY
country_code
Then, assigning a value like that to the JSON endpoint URL panel control setting, the machinery would interpolate the selected value assigned to the $countrycode variable appropriately.
Add basic variable interpolation based on keys from dataPoint. Saying that, all metric values have been added to the data point beforehand by prefixing them with "__field_" (source).
If there’s a field called station_id in the current data point, using this inside a panel control option is easy by addressing it with $__field_station_id.
All request parameters from the request URL are now available in the variable interpolation dictionary, prefixed by "request_". This enables using request variables in all panel control options (source, commit).
So, when invoking the dashboard with query parameters like
you would be able to use these variables from inside panel control options by assigning them appropriately.
By using request parameters prefixed with “panel-”, it is possible to override the panel control options at runtime (source, commit).
# Disable zoom control.
https://daq.example.org/d/D1Fx12kWk/magic-dashboard?panel-showZoomControl=false
# Add clickthrough-link, interpolating the geohash value.
?panel-clickthroughUrl=/path/to/?geohash=$__field_geohash
# Crazyness:
# Interpolate a custom request variable into
# the `clickthroughUrl` setting at runtime.
https://daq.example.org/d/D1Fx12kWk/magic-dashboard?panel-clickthroughUrl=/path/to/?foobar=$request_foobar&foobar=hello
We already support the last geohash center, it might be useful to also center on the first geohash received (commit).
Thanks for sharing that through #156, Fabien Pomerol.
"mapFitData" and "mapZoomByRadius"Both editor options provide a more convenient way to determine the viewport (center and zoom level) of the map view. Both features are using Leaflet’s getBoundsZoom() method, which
returns the maximum zoom level on which the given bounds fit to the map view in its entirety.
As the computation of "mapFitData" is based on the real data which actually covers a certain boundary, this should mostly do what I mean.
Enabling this option will choose an optimal center and zoom level for covering the displayed data (source).
This will use a bounding box of a respective circle with the designated radius around the chosen center for determining the viewport (source).
One of our data feeds suddenly started yielding empty "geohash" values into the database. The Worldmap Panel was not amused about it.
The Worldmap Panel should be able to compensate for that by operating it with an appropriate control option.
Complementing the options to ignore empty and zero metric values, the options to “Ignore empty geohash values” and “Ignore invalid geohash values” optionally should do what they promise (source, commit).
ignoreEscapeKey option.While this amends the global behaviour of Grafana and should probably be implemented elsewhere, it helps us now to prevent the user to leave the Kiosk mode.
– https://github.com/hiveeyes/grafana-worldmap-panel/commit/eea48c41d5fd338f841ba29e3d031004ab61671d
hideTimepickerNavigation option.This also amends global behaviour so it should be implemented elsewhere. However, it helps us now to improve Kiosk mode displays.
– https://github.com/hiveeyes/grafana-worldmap-panel/commit/e379a8b0de93bbc3a3aca4cbe8d9119c6b37f774
The default is “strokes enabled” with a stroke width of 3 pixels (left side). After disabling strokes, the circles display without borders (right side).
Pen Liner borders.
These settings control which alternative text is displayed in the attribution area of the Leaflet map widget (commit).
table+json and table+jsonp to retrievetableQueryOptions.labelLocationKeyField.autoPanLabels and autoWidthLabels to visual option settings.zoomControl and attributionControl to visual option settings.showTableOptions() conditional for signalling any type of table source.locationData: "table+json"showZoomControl: falseshowAttribution: falselegendContainerSelectorMakefile for macOS/Homebrew.dataPoint.dataPoint__field_ to avoid collisions.request_.clickthroughUrl interpolation.clickthroughOptions.windowName to open clickthrough target in designated window.Last Geohash.First Geohash centering (#156).mapFitData and mapZoomByRadius.ignoreEmptyGeohashValues and ignoreInvalidGeohashValues.ignoreEscapeKey option.hideTimepickerNavigation option.circleOptions.strokeEnabled and circleOptions.strokeWeight.customAttribution and customAttributionText.– grafana-worldmap-panel/CHANGELOG.md at develop · hiveeyes/grafana-worldmap-panel · GitHub