This release features the first version increment of the ValetudoMap data format.
Initially, in version 1, pixel data such as walls or floor were stored as a huge array of coordinate pairs:
[x0, y0, x1, y1, ...]. This was not a very efficient way of storing that data as most of it is redundant.
This resulted in map files that were over 1 MiB in size being pushed to your browser every 3 seconds.
To combat this, some thought was put into how the data is stored.
If you have a row of pixels, all of them will have the same y-coordinate, meaning that you only have to store that once.
People already figured that out in the 60s.
With Map V2, pixels are stored as [xStart0, y0, count0, xStart1, y1, count1, ...] where [xStart, y] is the starting point and count represents additional pixels with the same y-coordinate to the right.
This resulted in V2 map files using between 5% and 15% of the size of the equivalent V1 map.
The huge testfile map for example was compressed from 847 kB to 75 kB.
While this is a breaking change, the breakage actually isn't that big of a change as V2 can easily be converted back to V1.
In fact, running JSON.parse() on a V2 map and then converting it to a V1 one in memory is more than twice as fast as running JSON.parse() on a V1 map.
Since this change drastically reduces the traffic caused by live maps, I expect to see general usability and reliability
improvements in situations where the Wi-Fi reception isn't that great.
alexkn
commented
2 years ago
With the new Version of "Valetudo" 2021.12.0 the map is empty, with 2021.11.1 all worked fine.
Changelog: https://github.com/Hypfer/Valetudo/releases/tag/2021.12.0 Map data format changes
This release features the first version increment of the ValetudoMap data format. Initially, in version 1, pixel data such as walls or floor were stored as a huge array of coordinate pairs: [x0, y0, x1, y1, ...]. This was not a very efficient way of storing that data as most of it is redundant.
This resulted in map files that were over 1 MiB in size being pushed to your browser every 3 seconds.
To combat this, some thought was put into how the data is stored. If you have a row of pixels, all of them will have the same y-coordinate, meaning that you only have to store that once. People already figured that out in the 60s.
With Map V2, pixels are stored as [xStart0, y0, count0, xStart1, y1, count1, ...] where [xStart, y] is the starting point and count represents additional pixels with the same y-coordinate to the right.
This resulted in V2 map files using between 5% and 15% of the size of the equivalent V1 map. The huge testfile map for example was compressed from 847 kB to 75 kB.
While this is a breaking change, the breakage actually isn't that big of a change as V2 can easily be converted back to V1. In fact, running JSON.parse() on a V2 map and then converting it to a V1 one in memory is more than twice as fast as running JSON.parse() on a V1 map.
Since this change drastically reduces the traffic caused by live maps, I expect to see general usability and reliability improvements in situations where the Wi-Fi reception isn't that great.