organicmaps/organicmaps-tmp

Archived

Fork 1

Don't store (almost) duplicate geometry data #2927

New issue

Closed

opened 2022-07-05 18:32:34 +00:00 by pastk · 7 comments

pastk commented

2022-07-05 18:32:34 +00:00

Owner

However it looks like that often geo2 and geo3 geometries are (almost) identical. Perhaps due to the original OSM geometry being detailed just enough to satisfy OM's geo2's precision requirements but not geo3's.

So almost identical geo2 & 3 add storage size and cache overhead without actual performance benefits.

E.g. do you see a difference between those patches of forest in the middle and the river lines?
I do - but it took me a while to find one dot difference for the forest :)

For such situations it makes sense to omit geo2 and make the renderer use geo3.
(I guess for some simple features like a big square building all geo0..geo3 could be very well identical, so this optimization doesn't have to be limited to geo2/3 case only).

For comparison, this is how a difference between geo1 and geo2 (zl 12 & 13) looks like:

Drastic! 3 times less nodes perhaps.

We can define thresholds with some experimentation, but I think a lower geo should be at least twice more simple compared to the previous one.

OM has 4 versions of geometry (points / triangles) for each feature. The idea for that is to use simplified feature shapes on lower zooms to speed up by reading less data from the map file and rendering less elements. `geo0` is the simplest / worst geometry and `geo3` is the best / most detailed one. However it looks like that often `geo2` and `geo3` geometries are (almost) identical. Perhaps due to the original OSM geometry being detailed just enough to satisfy OM's geo2's precision requirements but not geo3's. So almost identical geo2 & 3 add storage size and cache overhead without actual performance benefits. E.g. do you see a difference between those patches of forest in the middle and the river lines? I do - but it took me a while to find one dot difference for the forest :) ![geometry-identical](https://user-images.githubusercontent.com/18434508/177391256-edb59999-5730-4c82-b847-25b10fbc9fe3.png) For such situations it makes sense to omit geo2 and make the renderer use geo3. (I guess for some simple features like a big square building all geo0..geo3 could be very well identical, so this optimization doesn't have to be limited to geo2/3 case only). For comparison, this is how a difference between geo1 and geo2 (zl 12 & 13) looks like: ![geometry-optimization](https://user-images.githubusercontent.com/18434508/177391617-49f5896e-3189-403f-aa1f-3818b421dc6b.png) Drastic! 3 times less nodes perhaps. We can define thresholds with some experimentation, but I think a lower geo should be at least twice more simple compared to the previous one.

Markus40 commented

2022-07-06 02:08:03 +00:00

(Migrated from github.com)

Could the finer (more detailed) layers use the data of the coarser (less detailed) layers?

Geo1 would just contain the data necessary to refine geo0. Geo2 would in turn contain the data to refine the geo0 + geo1 data. This would solve the mentioned problem of duplicated geometry because the finer layers of the examples would contain almost no data.

It could also allow for more levels without high storage consumption, which would result in smoother transitions.

I don't know what algorithm is used to simplify the map files, but if the coarser maps just use a subset of the vertices, combining different layers shouldn't involve too much computational cost.

Could the finer (more detailed) layers use the data of the coarser (less detailed) layers? Geo1 would just contain the data necessary to refine geo0. Geo2 would in turn contain the data to refine the geo0 + geo1 data. This would solve the mentioned problem of duplicated geometry because the finer layers of the examples would contain almost no data. It could also allow for more levels without high storage consumption, which would result in smoother transitions. I don't know what algorithm is used to simplify the map files, but if the coarser maps just use a subset of the vertices, combining different layers shouldn't involve too much computational cost.

pastk commented

2022-07-06 08:11:17 +00:00

Author

Owner

Could the finer (more detailed) layers use the data of the coarser (less detailed) layers?

The problem is the algo will need to know somehow where to insert the refining elements.
Let's take a line as a simpler example.
E.g. we have just 3 points for geo0 and 10 more for geo1. We'll need to add extra data to geo1 to define where these extra points go, e.g. it could be count of points in each geo1 block and pn a number of geo0 point after which they should be inserted.
Depending on the points counts ratio between geo levels this extra info could take similar or even more space than just storing a full geo1 geometry.

Another approach is to add 2 extra bits for each point, these 2 bits store geo level index (0..3). So its easy to filter all points for e.g. geo0..2 except geo3. This approach is used already for short lines as their points are stored inline in feature's header whereas points for longer lines are stored "outside" at some offset in the file (each geo has its own offset).
If we use this approach for longer lines too then we won't have duplication, but we will lose a major benefit of having to read and load less data for lower zoom levels.

And it gets much more complicated for triangles (area objects) as for each geo level the area needs to be tessellated into triangles and run-time tesselation doesn't look like a good idea.

Well, there is a broad field for experimentation here for sure.
And actually there should be established best practices approaches for these problems as its not an OM-specific thing.
Do you know them maybe?

Its better to discuss in a separate issue or discussion thread perhaps.

> Could the finer (more detailed) layers use the data of the coarser (less detailed) layers? > The problem is the algo will need to know somehow where to insert the refining elements. Let's take a line as a simpler example. E.g. we have just 3 points for geo0 and 10 more for geo1. We'll need to add extra data to geo1 to define where these extra points go, e.g. it could be `count` of points in each geo1 block and `pn` a number of geo0 point after which they should be inserted. Depending on the points counts ratio between geo levels this extra info could take similar or even more space than just storing a full geo1 geometry. Another approach is to add 2 extra bits for each point, these 2 bits store geo level index (0..3). So its easy to filter all points for e.g. geo0..2 except geo3. This approach is used already for short lines as their points are stored inline in feature's header whereas points for longer lines are stored "outside" at some offset in the file (each geo has its own offset). If we use this approach for longer lines too then we won't have duplication, but we will lose a major benefit of having to read and load less data for lower zoom levels. And it gets much more complicated for triangles (area objects) as for each geo level the area needs to be tessellated into triangles and run-time tesselation doesn't look like a good idea. Well, there is a broad field for experimentation here for sure. And actually there should be established best practices approaches for these problems as its not an OM-specific thing. Do you know them maybe? Its better to discuss in a separate issue or discussion thread perhaps.

Markus40 commented

2022-07-06 13:18:02 +00:00

(Migrated from github.com)

And actually there should be established best practices approaches for these problems as its not an OM-specific thing.
Do you know them maybe?

Unfortunately not. I have looked a bit but it seems to be difficult to search for.

I stupidly didn't take into account that the vector data is not numbered. I don't know how efficient you save/compress the vector data but if we assume that you use a simple representation and use 24 bits of data for every vector, a very simple absolute count (where every vector is numbered) would add anywhere from 25% - 85% overhead depending on line length. I am sure that this can be greatly optimised at the cost of a bit more computation. How much space do geo0 - geo2 need compared to geo3?

This would have to be discussed with the community, but if it really is not possible to optimise it sufficiently, it could very well be that a slightly higher storage consumption is acceptable if you get more layers and smoother transitions.

Unfortunately, I don't have much time at the moment, the university exam period is starting now, so I can't start any major projects. Maybe I can take a closer look when I have more time.

> And actually there should be established best practices approaches for these problems as its not an OM-specific thing. Do you know them maybe? Unfortunately not. I have looked a bit but it seems to be difficult to search for. I stupidly didn't take into account that the vector data is not numbered. I don't know how efficient you save/compress the vector data but if we assume that you use a simple representation and use 24 bits of data for every vector, a very simple absolute count (where every vector is numbered) would add anywhere from 25% - 85% overhead depending on line length. I am sure that this can be greatly optimised at the cost of a bit more computation. How much space do geo0 - geo2 need compared to geo3? This would have to be discussed with the community, but if it really is not possible to optimise it sufficiently, it could very well be that a slightly higher storage consumption is acceptable if you get more layers and smoother transitions. Unfortunately, I don't have much time at the moment, the university exam period is starting now, so I can't start any major projects. Maybe I can take a closer look when I have more time.

pastk commented

2022-07-06 15:12:43 +00:00

Author

Owner

This would have to be discussed with the community, but if it really is not possible to optimise it sufficiently, it could very well be that a slightly higher storage consumption is acceptable if you get more layers and smoother transitions.

TBH I don't think we need more geometry versions. Actually in my testing of #2798 I was surprised how little was the performance impact of resorting to a more detailed geo level instead of a "regular" one for a given zoom level.

What makes a "transition" look smooth is not number of geometry versions but at which point its being switched. A switch to a simpler geometry should take place not before it has enough points to look smooth at a given zoom level.

> > This would have to be discussed with the community, but if it really is not possible to optimise it sufficiently, it could very well be that a slightly higher storage consumption is acceptable if you get more layers and smoother transitions. TBH I don't think we need more geometry versions. Actually in my testing of #2798 I was surprised how little was the performance impact of resorting to a more detailed geo level instead of a "regular" one for a given zoom level. What makes a "transition" look smooth is not number of geometry versions but at which point its being switched. A switch to a simpler geometry should take place not before it has enough points to look smooth at a given zoom level.

Markus40 commented

2022-07-07 03:13:02 +00:00

(Migrated from github.com)

When I have a little more time, I will look into it. I am optimistic that it will be possible to save a little storage space compared to simply duplicating the data.

pastk commented

2022-07-08 12:23:34 +00:00

Author

Owner

I got some sample stats via #2935.

For a big city:
87.8MB map file (geometry takes ~21% total size).
0.3MB (0.3% of map file size) potential saving at 1.5x threshold, 0.6Mb (0.7%) at 2.0x.

Outer LINE geometry
geom0   : size =      8066: elements =      3363; features =    1224; elems/feats =   2.7; bytes/elems =  2.4
geom1w/0: size =     16527: elements =      6034; feats w/geom0 =    1224; elems/feats =   4.9; size factor =  2.0x; elems factor =  1.8x
geom1   : size =     47273: elements =     18127; features =    4968; elems/feats =   3.6; bytes/elems =  2.6
geom2w/1: size =     91131: elements =     32444; feats w/geom1 =    4968; elems/feats =   6.5; size factor =  1.9x; elems factor =  1.8x
geom2   : size =    337852: elements =    123387; features =   15429; elems/feats =   8.0; bytes/elems =  2.7
geom3w/2: size =   1074982: elements =    443151; feats w/geom2 =   15429; elems/feats =  28.7; size factor =  3.2x; elems factor =  3.6x
geom3   : size =   2144001: elements =    884881; features =   27393; elems/feats =  32.3; bytes/elems =  2.4
Geometry almost duplicating (<1.5x less elements) a more detailed one
geom0~=1: size =      2399: elements =      1114; features =     511; elems/feats =   2.2; dups size % = 29%
geom1~=2: size =     14919: elements =      5908; features =    1874; elems/feats =   3.2; dups size % = 31%
geom2~=3: size =     12738: elements =      4382; features =     206; elems/feats =  21.3; dups size % =  3%
Geometry almost duplicating (<2.0x less elements) a more detailed one
geom0~=1: size =      4989: elements =      2222; features =     950; elems/feats =   2.3; dups size % = 61%
geom1~=2: size =     32120: elements =     12549; features =    3735; elems/feats =   3.4; dups size % = 67%
geom2~=3: size =     46430: elements =     16455; features =     850; elems/feats =  19.4; dups size % = 13%

Outer AREA geometry
trg0   : size =     39552: elements =      6751; features =    1069; elems/feats =   6.3; bytes/elems =  5.9
trg1w/0: size =    111817: elements =     27359; feats w/trg0 =    1069; elems/feats =  25.6; size factor =  2.8x; elems factor =  4.1x
trg1   : size =    240936: elements =     47247; features =    5669; elems/feats =   8.3; bytes/elems =  5.1
trg2w/1: size =    555692: elements =    143876; feats w/trg1 =    5669; elems/feats =  25.4; size factor =  2.3x; elems factor =  3.0x
trg2   : size =   1368159: elements =    293559; features =   36627; elems/feats =   8.0; bytes/elems =  4.7
trg3w/2: size =   3189372: elements =    957848; feats w/trg2 =   36627; elems/feats =  26.2; size factor =  2.3x; elems factor =  3.3x
trg3   : size =   4049072: elements =   1211546; features =   55343; elems/feats =  21.9; bytes/elems =  3.3
Geometry almost duplicating (<1.5x less elements) a more detailed one
trg0~=1: size =       151: elements =        15; features =       6; elems/feats =   2.5; dups size % =  0%
trg1~=2: size =      6003: elements =      1241; features =     136; elems/feats =   9.1; dups size % =  2%
trg2~=3: size =    246450: elements =     63339; features =    3688; elems/feats =  17.2; dups size % = 18%
Geometry almost duplicating (<2.0x less elements) a more detailed one
trg0~=1: size =       905: elements =       121; features =      35; elems/feats =   3.5; dups size % =  2%
trg1~=2: size =     39209: elements =      8855; features =     600; elems/feats =  14.8; dups size % = 16%
trg2~=3: size =    461494: elements =    116964; features =    7070; elems/feats =  16.5; dups size % = 33%

For a small region:
26.5MB map file (geometry takes ~70% total size).
1.4MB (5% of map file size) potential saving at 1.5x threshold, 2.3Mb (9%) at 2.0x.

Outer LINE geometry
geom0   : size =     14355: elements =      4751; features =     650; elems/feats =   7.3; bytes/elems =  3.0
geom1w/0: size =     48764: elements =     16096; feats w/geom0 =     650; elems/feats =  24.8; size factor =  3.4x; elems factor =  3.4x
geom1   : size =     78810: elements =     26988; features =    3262; elems/feats =   8.3; bytes/elems =  2.9
geom2w/1: size =    174512: elements =     59613; feats w/geom1 =    3262; elems/feats =  18.3; size factor =  2.2x; elems factor =  2.2x
geom2   : size =   1068665: elements =    374913; features =   15426; elems/feats =  24.3; bytes/elems =  2.9
geom3w/2: size =   2249686: elements =    843519; feats w/geom2 =   15426; elems/feats =  54.7; size factor =  2.1x; elems factor =  2.2x
geom3   : size =   5885068: elements =   2209425; features =   28307; elems/feats =  78.1; bytes/elems =  2.7
Geometry almost duplicating (<1.5x less elements) a more detailed one
geom0~=1: size =      2065: elements =       689; features =     135; elems/feats =   5.1; dups size % = 14%
geom1~=2: size =     11554: elements =      4008; features =     777; elems/feats =   5.2; dups size % = 14%
geom2~=3: size =    214457: elements =     73798; features =    2534; elems/feats =  29.1; dups size % = 20%
Geometry almost duplicating (<2.0x less elements) a more detailed one
geom0~=1: size =      3930: elements =      1307; features =     262; elems/feats =   5.0; dups size % = 27%
geom1~=2: size =     32662: elements =     11290; features =    1853; elems/feats =   6.1; dups size % = 41%
geom2~=3: size =    562072: elements =    196878; features =    5585; elems/feats =  35.3; dups size % = 52%

Outer AREA geometry
trg0   : size =    203673: elements =     40681; features =    3355; elems/feats =  12.1; bytes/elems =  5.0
trg1w/0: size =    604080: elements =    155702; feats w/trg0 =    3355; elems/feats =  46.4; size factor =  3.0x; elems factor =  3.8x
trg1   : size =    859230: elements =    204763; features =   10289; elems/feats =  19.9; bytes/elems =  4.2
trg2w/1: size =   1861674: elements =    504368; feats w/trg1 =   10289; elems/feats =  49.0; size factor =  2.2x; elems factor =  2.5x
trg2   : size =   2075253: elements =    545051; features =   18169; elems/feats =  30.0; bytes/elems =  3.8
trg3w/2: size =   4096561: elements =   1174955; feats w/trg2 =   18169; elems/feats =  64.7; size factor =  2.0x; elems factor =  2.2x
trg3   : size =   4299267: elements =   1227069; features =   24519; elems/feats =  50.0; bytes/elems =  3.5
Geometry almost duplicating (<1.5x less elements) a more detailed one
trg0~=1: size =      1304: elements =       200; features =      44; elems/feats =   4.5; dups size % =  0%
trg1~=2: size =    137969: elements =     35611; features =     753; elems/feats =  47.3; dups size % = 16%
trg2~=3: size =   1066718: elements =    281620; features =    5185; elems/feats =  54.3; dups size % = 51%
Geometry almost duplicating (<2.0x less elements) a more detailed one
trg0~=1: size =      6277: elements =      1161; features =     154; elems/feats =   7.5; dups size % =  3%
trg1~=2: size =    359281: elements =     92919; features =    1991; elems/feats =  46.7; dups size % = 41%
trg2~=3: size =   1348604: elements =    357737; features =    7428; elems/feats =  48.2; dups size % = 64%

Need to assess performance impact (data reading, rendering) somehow to get a better idea of a feasible threshold level.

I got some sample stats via #2935. For a big city: 87.8MB map file (geometry takes ~21% total size). 0.3MB (0.3% of map file size) potential saving at 1.5x threshold, 0.6Mb (0.7%) at 2.0x. ``` Outer LINE geometry geom0 : size = 8066: elements = 3363; features = 1224; elems/feats = 2.7; bytes/elems = 2.4 geom1w/0: size = 16527: elements = 6034; feats w/geom0 = 1224; elems/feats = 4.9; size factor = 2.0x; elems factor = 1.8x geom1 : size = 47273: elements = 18127; features = 4968; elems/feats = 3.6; bytes/elems = 2.6 geom2w/1: size = 91131: elements = 32444; feats w/geom1 = 4968; elems/feats = 6.5; size factor = 1.9x; elems factor = 1.8x geom2 : size = 337852: elements = 123387; features = 15429; elems/feats = 8.0; bytes/elems = 2.7 geom3w/2: size = 1074982: elements = 443151; feats w/geom2 = 15429; elems/feats = 28.7; size factor = 3.2x; elems factor = 3.6x geom3 : size = 2144001: elements = 884881; features = 27393; elems/feats = 32.3; bytes/elems = 2.4 Geometry almost duplicating (<1.5x less elements) a more detailed one geom0~=1: size = 2399: elements = 1114; features = 511; elems/feats = 2.2; dups size % = 29% geom1~=2: size = 14919: elements = 5908; features = 1874; elems/feats = 3.2; dups size % = 31% geom2~=3: size = 12738: elements = 4382; features = 206; elems/feats = 21.3; dups size % = 3% Geometry almost duplicating (<2.0x less elements) a more detailed one geom0~=1: size = 4989: elements = 2222; features = 950; elems/feats = 2.3; dups size % = 61% geom1~=2: size = 32120: elements = 12549; features = 3735; elems/feats = 3.4; dups size % = 67% geom2~=3: size = 46430: elements = 16455; features = 850; elems/feats = 19.4; dups size % = 13% Outer AREA geometry trg0 : size = 39552: elements = 6751; features = 1069; elems/feats = 6.3; bytes/elems = 5.9 trg1w/0: size = 111817: elements = 27359; feats w/trg0 = 1069; elems/feats = 25.6; size factor = 2.8x; elems factor = 4.1x trg1 : size = 240936: elements = 47247; features = 5669; elems/feats = 8.3; bytes/elems = 5.1 trg2w/1: size = 555692: elements = 143876; feats w/trg1 = 5669; elems/feats = 25.4; size factor = 2.3x; elems factor = 3.0x trg2 : size = 1368159: elements = 293559; features = 36627; elems/feats = 8.0; bytes/elems = 4.7 trg3w/2: size = 3189372: elements = 957848; feats w/trg2 = 36627; elems/feats = 26.2; size factor = 2.3x; elems factor = 3.3x trg3 : size = 4049072: elements = 1211546; features = 55343; elems/feats = 21.9; bytes/elems = 3.3 Geometry almost duplicating (<1.5x less elements) a more detailed one trg0~=1: size = 151: elements = 15; features = 6; elems/feats = 2.5; dups size % = 0% trg1~=2: size = 6003: elements = 1241; features = 136; elems/feats = 9.1; dups size % = 2% trg2~=3: size = 246450: elements = 63339; features = 3688; elems/feats = 17.2; dups size % = 18% Geometry almost duplicating (<2.0x less elements) a more detailed one trg0~=1: size = 905: elements = 121; features = 35; elems/feats = 3.5; dups size % = 2% trg1~=2: size = 39209: elements = 8855; features = 600; elems/feats = 14.8; dups size % = 16% trg2~=3: size = 461494: elements = 116964; features = 7070; elems/feats = 16.5; dups size % = 33% ``` For a small region: 26.5MB map file (geometry takes ~70% total size). 1.4MB (5% of map file size) potential saving at 1.5x threshold, 2.3Mb (9%) at 2.0x. ``` Outer LINE geometry geom0 : size = 14355: elements = 4751; features = 650; elems/feats = 7.3; bytes/elems = 3.0 geom1w/0: size = 48764: elements = 16096; feats w/geom0 = 650; elems/feats = 24.8; size factor = 3.4x; elems factor = 3.4x geom1 : size = 78810: elements = 26988; features = 3262; elems/feats = 8.3; bytes/elems = 2.9 geom2w/1: size = 174512: elements = 59613; feats w/geom1 = 3262; elems/feats = 18.3; size factor = 2.2x; elems factor = 2.2x geom2 : size = 1068665: elements = 374913; features = 15426; elems/feats = 24.3; bytes/elems = 2.9 geom3w/2: size = 2249686: elements = 843519; feats w/geom2 = 15426; elems/feats = 54.7; size factor = 2.1x; elems factor = 2.2x geom3 : size = 5885068: elements = 2209425; features = 28307; elems/feats = 78.1; bytes/elems = 2.7 Geometry almost duplicating (<1.5x less elements) a more detailed one geom0~=1: size = 2065: elements = 689; features = 135; elems/feats = 5.1; dups size % = 14% geom1~=2: size = 11554: elements = 4008; features = 777; elems/feats = 5.2; dups size % = 14% geom2~=3: size = 214457: elements = 73798; features = 2534; elems/feats = 29.1; dups size % = 20% Geometry almost duplicating (<2.0x less elements) a more detailed one geom0~=1: size = 3930: elements = 1307; features = 262; elems/feats = 5.0; dups size % = 27% geom1~=2: size = 32662: elements = 11290; features = 1853; elems/feats = 6.1; dups size % = 41% geom2~=3: size = 562072: elements = 196878; features = 5585; elems/feats = 35.3; dups size % = 52% Outer AREA geometry trg0 : size = 203673: elements = 40681; features = 3355; elems/feats = 12.1; bytes/elems = 5.0 trg1w/0: size = 604080: elements = 155702; feats w/trg0 = 3355; elems/feats = 46.4; size factor = 3.0x; elems factor = 3.8x trg1 : size = 859230: elements = 204763; features = 10289; elems/feats = 19.9; bytes/elems = 4.2 trg2w/1: size = 1861674: elements = 504368; feats w/trg1 = 10289; elems/feats = 49.0; size factor = 2.2x; elems factor = 2.5x trg2 : size = 2075253: elements = 545051; features = 18169; elems/feats = 30.0; bytes/elems = 3.8 trg3w/2: size = 4096561: elements = 1174955; feats w/trg2 = 18169; elems/feats = 64.7; size factor = 2.0x; elems factor = 2.2x trg3 : size = 4299267: elements = 1227069; features = 24519; elems/feats = 50.0; bytes/elems = 3.5 Geometry almost duplicating (<1.5x less elements) a more detailed one trg0~=1: size = 1304: elements = 200; features = 44; elems/feats = 4.5; dups size % = 0% trg1~=2: size = 137969: elements = 35611; features = 753; elems/feats = 47.3; dups size % = 16% trg2~=3: size = 1066718: elements = 281620; features = 5185; elems/feats = 54.3; dups size % = 51% Geometry almost duplicating (<2.0x less elements) a more detailed one trg0~=1: size = 6277: elements = 1161; features = 154; elems/feats = 7.5; dups size % = 3% trg1~=2: size = 359281: elements = 92919; features = 1991; elems/feats = 46.7; dups size % = 41% trg2~=3: size = 1348604: elements = 357737; features = 7428; elems/feats = 48.2; dups size % = 64% ``` Need to assess performance impact (data reading, rendering) somehow to get a better idea of a feasible threshold level.

pastk commented

2022-07-11 15:28:40 +00:00

Author

Owner

Need to assess performance impact (data reading, rendering) somehow to get a better idea of a feasible threshold level.

Here are very rough performance benchmarks I did, but they can give some idea anyway.
I've prepared a build (see branch pastk-styles-geometryfallback-1more-detailed) that allows to switch between a "regular" geometry or force to one level more detailed, e.g. for a zoom level 10 instead of geo0 a geo1 (regularly meant for zl 12) will be used.
Upd: I've added results for forcing use of the most detailed (best) geo3 geometry on any zl.
I measured with a stop-watch :) a time it takes to render a center of a very big city (Moscow) when changing zoom level 11 to 10 and 10 to 11. Some (if not most) data was likely cached by the app and Android. So results could be different for a "cold" render.

A slow low-end Asus ZB501KL

              regular     +1 more detailed     the most detailed
zl 11 => 10:   ~8.5-9s         ~9-9.5s             ~12-12.7s
zl 10 => 11:   ~13-13.5s       ~14-14.5s           ~17-18s

A mid-range Xiaomi Mi A2 Lite

              regular     +1 more detailed     the most detailed
zl 11 => 10:   ~4.5s         ~4.7s                 ~5.1-5.3s
zl 10 => 11:   ~6.5s         ~6.7s                 ~7.1-7.3s

So we can say that:

big cities are rendered (very) slowly
2x more points and 3-4x more triangles (see Moscow stats above) to read/render have a surprisingly small effect on overall performance
geometry complexity/size is not a major performance bottleneck atm
if we omit almost-duplicate geometries a performance downgrade is likely to be negligible (it'll affect a fraction of features only while this test was forced for all features)

It'll be great to have this kind of performance benchmark automated.

Update: added stats for using the most detailed geometry always.

> Need to assess performance impact (data reading, rendering) somehow to get a better idea of a feasible threshold level. Here are very rough performance benchmarks I did, but they can give some idea anyway. I've prepared a build (see branch [`pastk-styles-geometryfallback-1more-detailed`](https://github.com/organicmaps/organicmaps/tree/pastk-styles-geometryfallback-1more-detailed)) that allows to switch between a "regular" geometry or force to one level more detailed, e.g. for a zoom level 10 instead of `geo0` a `geo1` (regularly meant for zl 12) will be used. Upd: I've added results for forcing use of the most detailed (best) `geo3` geometry on any zl. I measured with a stop-watch :) a time it takes to render a center of a very big city (Moscow) when changing zoom level 11 to 10 and 10 to 11. Some (if not most) data was likely cached by the app and Android. So results could be different for a "cold" render. 1. A slow low-end [Asus ZB501KL](https://www.gsmarena.com/asus_zenfone_live_zb501kl-8579.php) ``` regular +1 more detailed the most detailed zl 11 => 10: ~8.5-9s ~9-9.5s ~12-12.7s zl 10 => 11: ~13-13.5s ~14-14.5s ~17-18s ``` 1. A mid-range [Xiaomi Mi A2 Lite](https://www.gsmarena.com/xiaomi_mi_a2_lite_(redmi_6_pro)-9247.php) ``` regular +1 more detailed the most detailed zl 11 => 10: ~4.5s ~4.7s ~5.1-5.3s zl 10 => 11: ~6.5s ~6.7s ~7.1-7.3s ``` So we can say that: - big cities are rendered (very) slowly - 2x more points and 3-4x more triangles (see Moscow stats above) to read/render have a surprisingly small effect on overall performance - geometry complexity/size is not a major performance bottleneck atm - if we omit almost-duplicate geometries a performance downgrade is likely to be negligible (it'll affect a fraction of features only while this test was forced for all features) It'll be great to have this kind of performance benchmark automated. Update: added stats for using the most detailed geometry always.

This repo is archived. You cannot comment on issues.