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? As for multipolygons - I would say the total size of all splitted parts rather than inside the relations file. (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