I'm trying to reverse-engineer the weather maps of the Swiss Weather service because I want to extract information for display on some e-paper displays. You can see such a map here: https://www.meteosuisse.admin.ch/services-et-publications/applications/precipitations.html
The overlay I'm interested in is contained in JSON files with names following the pattern rate_YYYYMMDD_hhmm.json
. It contains an array of "areas", each given by an RGB colour and an array of "shapes". So far, so good. However I don't understand the encoding used for those shapes. Here is an example:
{"i":621,"j":120,"d":"NLNLNLNNMOLNKM","o":"01257867","l":0}
I'm guessing i
and j
are the location of the shape and d
and o
somehow describe its boundary? I noticed that d.length
is always equal to (o.length - 1) * 2
, and l
seems to be equal to the index of the shape in the area's shape array.
d
seems to only use N
, M
, K
, L
and O
.
o
seems to use all digits between 0
and 9
.
Does anyone recognise this? Is it standard, or at least some format used by some library? The JavaScript is obfuscated so it's hard to figure out where this is being parsed.
Ok it doesn't look like this is a standard encoding. The decoding function is called f
in the obfuscated Javascript of the page and works roughly as follows:
i
and j
are coordinates of a one vertex of the polygond
indicate in which direction to go for the next vertex. Letters from K
to O
are mapped to offsets from -2 to +2. For instance the initial NL
moves from (621; 120)
to (621+1; 120-1)
o
provide additional precision by specifying an offset between 0.05
and 0.95
. For some reason the encoding only allows adding such an offset on either the horizontal coordinate (if it is an odd number) or the vertical coordinate (if the horizontal coordinate is odd).CHtoWGS
in the same file, presumably to convert to one of the WGS coordinate systems.