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