[mkgmap-dev] [PATCH v1] garmin_area() style function

Sat Jul 13 13:48:20 BST 2013

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 at 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.mkgmap.org.uk/pipermail/mkgmap-dev/attachments/20130713/40d4ad46/attachment.html 