more refined mkgmap:skipSizeFilter=true handling
Well, the skip filter function works well, but there are problems with it - especially on South America. For South America geofabrik extract - the overview map gets rather large. Using higher polygon size on filter - would be the essential tool in order too keep the overview .img file to be getting too large, without nearly any visual deterioration. a) A quick (or I hope that would be quick) adaption could be to have instead: mkgmap:changeSizeFilter=? with ? being the number for the filter to be used. Even a value of 2, would have quite good effect in case of South America. (about 15% saving on the overview.img size with default style). b) A more optimal solution would be the following: mkgmap:changeSizeFilter="level:filter_strenght" so e.g. "0:12, 1:12, 3:12, 4:12, 5:10, 6:8, 7:8, 8:4, 9:2, 10:1" A filter working this way, would have great impact on the overview.img size, as well as normal map.img size - without leading to strong visual impact. (up to 50% saving on the overview.img size) The effect of the polygon size filter on South America is especially strong, as there is a huge sea area included in the extract... (also I still don't understand, why mkgmap makes so small squares for the sea, instead of larger squares - which should also save on .img size).
But this should be handled in options. Like: min-size-polygon="0:12, 1:12, 3:12, 4:12, 5:10, 6:8, 7:8, 8:4, 9:2, 10:1" Or is it necessary to handle it different for different polygon types? Henning Am 14.05.2013 23:25, schrieb Felix Hartmann:
b) A more optimal solution would be the following: mkgmap:changeSizeFilter="level:filter_strenght" so e.g. "0:12, 1:12, 3:12, 4:12, 5:10, 6:8, 7:8, 8:4, 9:2, 10:1" A filter working this way, would have great impact on the overview.img size, as well as normal map.img size - without leading to strong visual impact. (up to 50% saving on the overview.img size)
for me not (I only need it for sea anyhow). but the current implementation is to have the mkgmap:skipSizeFilter=true to be added to the style-file. min-size-polygon="0:12, 1:12, 3:12, 4:12, 5:10, 6:8, 7:8, 8:4, 9:2, 10:1" or similar was my original request for this... On 14.05.2013 17:47, Henning Scholland wrote:
But this should be handled in options. Like:
min-size-polygon="0:12, 1:12, 3:12, 4:12, 5:10, 6:8, 7:8, 8:4, 9:2, 10:1"
Or is it necessary to handle it different for different polygon types?
Henning
Am 14.05.2013 23:25, schrieb Felix Hartmann:
b) A more optimal solution would be the following: mkgmap:changeSizeFilter="level:filter_strenght" so e.g. "0:12, 1:12, 3:12, 4:12, 5:10, 6:8, 7:8, 8:4, 9:2, 10:1" A filter working this way, would have great impact on the overview.img size, as well as normal map.img size - without leading to strong visual impact. (up to 50% saving on the overview.img size)
Hi, I'll implement a parm like min-size-polygon="0:12, 1:12, 3:12, 4:12, 5:10, 6:8, 7:8, 8:4, 9:2, 10:1" @WanMil: I also like the idea that SeaGenerator should try to generate larger polygons. I assume it should be sufficient to merge the land-only and sea-only rectangles. This will not create too complex shapes which would then cause run time problems in the split process. Gerd Felix Hartmann-2 wrote
for me not (I only need it for sea anyhow). but the current implementation is to have the mkgmap:skipSizeFilter=true to be added to the style-file. min-size-polygon="0:12, 1:12, 3:12, 4:12, 5:10, 6:8, 7:8, 8:4, 9:2, 10:1" or similar was my original request for this...
On 14.05.2013 17:47, Henning Scholland wrote:
But this should be handled in options. Like:
min-size-polygon="0:12, 1:12, 3:12, 4:12, 5:10, 6:8, 7:8, 8:4, 9:2, 10:1"
Or is it necessary to handle it different for different polygon types?
Henning
Am 14.05.2013 23:25, schrieb Felix Hartmann:
b) A more optimal solution would be the following: mkgmap:changeSizeFilter="level:filter_strenght" so e.g. "0:12, 1:12, 3:12, 4:12, 5:10, 6:8, 7:8, 8:4, 9:2, 10:1" A filter working this way, would have great impact on the overview.img size, as well as normal map.img size - without leading to strong visual impact. (up to 50% saving on the overview.img size)
_______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
-- View this message in context: http://gis.19327.n5.nabble.com/more-refined-mkgmap-skipSizeFilter-true-handl... Sent from the Mkgmap Development mailing list archive at Nabble.com.
Hi, I've committed r2609 that implements new option polygon-size-limits. It turned out to be rather complicated to use the levels value, so I decided to use the resolution. If given and syntactically correct, the option overrides the value for min-size-polygon. I hope that helps... I do now try to find a solution for the small sea/land polygons. Gerd --polygon-size-limits=limits code Allows to specify different min-size-polygon values for each resolution. Sample: --polygon-size-limits="24:12, 18:10, 16:8, 14:4, 12:2, 10:0" If a resolution is not given, mkgmap uses the value for the next higher one. For the given sample, resolutions 19 to 24 will use value 12, resolution 17 and 18 will use 10, and so on. Value 0 means to skip the size filter. Note that in resolution 24 the filter is not used. Felix Hartmann-2 wrote
for me not (I only need it for sea anyhow). but the current implementation is to have the mkgmap:skipSizeFilter=true to be added to the style-file. min-size-polygon="0:12, 1:12, 3:12, 4:12, 5:10, 6:8, 7:8, 8:4, 9:2, 10:1" or similar was my original request for this...
On 14.05.2013 17:47, Henning Scholland wrote:
But this should be handled in options. Like:
min-size-polygon="0:12, 1:12, 3:12, 4:12, 5:10, 6:8, 7:8, 8:4, 9:2, 10:1"
Or is it necessary to handle it different for different polygon types?
Henning
Am 14.05.2013 23:25, schrieb Felix Hartmann:
b) A more optimal solution would be the following: mkgmap:changeSizeFilter="level:filter_strenght" so e.g. "0:12, 1:12, 3:12, 4:12, 5:10, 6:8, 7:8, 8:4, 9:2, 10:1" A filter working this way, would have great impact on the overview.img size, as well as normal map.img size - without leading to strong visual impact. (up to 50% saving on the overview.img size)
_______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
-- View this message in context: http://gis.19327.n5.nabble.com/more-refined-mkgmap-skipSizeFilter-true-handl... Sent from the Mkgmap Development mailing list archive at Nabble.com.
forgot to mention that it is r2609 in the overview2 branch. Gerd GerdP wrote
Hi,
I've committed r2609 that implements new option polygon-size-limits. It turned out to be rather complicated to use the levels value, so I decided to use the resolution.
If given and syntactically correct, the option overrides the value for min-size-polygon.
I hope that helps... I do now try to find a solution for the small sea/land polygons.
Gerd
--polygon-size-limits=limits code Allows to specify different min-size-polygon values for each resolution. Sample: --polygon-size-limits="24:12, 18:10, 16:8, 14:4, 12:2, 10:0" If a resolution is not given, mkgmap uses the value for the next higher one. For the given sample, resolutions 19 to 24 will use value 12, resolution 17 and 18 will use 10, and so on. Value 0 means to skip the size filter. Note that in resolution 24 the filter is not used.
Felix Hartmann-2 wrote
for me not (I only need it for sea anyhow). but the current implementation is to have the mkgmap:skipSizeFilter=true to be added to the style-file. min-size-polygon="0:12, 1:12, 3:12, 4:12, 5:10, 6:8, 7:8, 8:4, 9:2, 10:1" or similar was my original request for this...
On 14.05.2013 17:47, Henning Scholland wrote:
But this should be handled in options. Like:
min-size-polygon="0:12, 1:12, 3:12, 4:12, 5:10, 6:8, 7:8, 8:4, 9:2, 10:1"
Or is it necessary to handle it different for different polygon types?
Henning
Am 14.05.2013 23:25, schrieb Felix Hartmann:
b) A more optimal solution would be the following: mkgmap:changeSizeFilter="level:filter_strenght" so e.g. "0:12, 1:12, 3:12, 4:12, 5:10, 6:8, 7:8, 8:4, 9:2, 10:1" A filter working this way, would have great impact on the overview.img size, as well as normal map.img size - without leading to strong visual impact. (up to 50% saving on the overview.img size)
_______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
-- View this message in context: http://gis.19327.n5.nabble.com/more-refined-mkgmap-skipSizeFilter-true-handl... Sent from the Mkgmap Development mailing list archive at Nabble.com.
Hi, Felix Hartmann-2 wrote
(also I still don't understand, why mkgmap makes so small squares for the sea, instead of larger squares - which should also save on .img size).
I've committed r2610 in the overview2 branch which generates fewer polygons. It combines land-only and sea-only polygons first. This seems to improve speed and decreases the img size. There is still one problem left: The SeaGenerator uses a raster of 32768 map units, means, it is very likely to generate polygons with a max dimension of 32768. The maximum allowed value in mkgmap is 0x7fff (32767), so many of the polygons created by the SeaGenerator are split into smaller parts just because of this one map unit. In some sources we use the test <= 0x7fff, in others < 0x7fff. If I got this right, the limit is not really the size of the polygon, but the largest offset from any of its points to the center of the sub division. With a max dimension less than 0x7fff we just make sure that this offset can't be > 0x7fff. So, it might be possible to allow a max dimension of 327678 if we make sure that the sub division center is not too far away from the center of the largest polygon in it. Gerd -- View this message in context: http://gis.19327.n5.nabble.com/more-refined-mkgmap-skipSizeFilter-true-handl... Sent from the Mkgmap Development mailing list archive at Nabble.com.
participants (3)
-
Felix Hartmann -
GerdP -
Henning Scholland