So actually this is a possibility to get rid of nonclosed shapes that cause "flooding" or similar stuff too I suppose, great!
At which resolution is it calculating the area? Always 24, or the size at each resolution?
The size is calculated at resolution 24 only.
As for multipolygons - I would say the total size of all splitted parts rather than inside the relations file.
Yep, I have just comitted it. I did not have time to test it carefully but the changes hopefully will not hurt :-)
(which would actually get a bit closer to the problem, that at lower resolutions, the cutouts from multipolygons shouldn't be cut out - e.g. for a forest at 21 or below - only look at the outer line, and do not cut out parts - especially if empty, but that's a completly different topic).
On 11.07.2013 23:04, WanMil wrote:
The patch adds a new style function called garmin_area(). garmin_area() returns the size of an area in garmin-units ^2. It works for polygons only. Unclosed ways return 0.
Please test it and let me know: * Do you have a better name? * What to do with multipolygons? Should garmin_area() return the multipolygon size for all splitted parts of the mp? or: Should it be possible to use garmin_area() in the relations file? In this case it would be possible to add tags to all members which can then be used in the polygons file. Example: type=multipolygon & building=yes & garmin_area() > 20000 { apply { set mkgmap:bigbuilding=yes; } }
Have fun! WanMil
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
-- keep on biking and discovering new trails
Felix openmtbmap.org &www.velomap.org
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev