[PATCH v1] garmin_area() style function
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
A build including the patch can be obtained here: http://files.mkgmap.org.uk/detail/146 WanMil
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
Hi WanMil, great work! Am 11.07.2013 23:04, schrieb WanMil:
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 about polygon_size() or area_size() ?
* What to do with multipolygons? Should garmin_area() return the multipolygon size for all splitted parts of the mp? For me this would be the prefered solution, because the user have not to care about polygon/multipolygon.
Henning
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
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
Actually, after using it, I think it is checked for each resolution! I have some stuff disappearing at 23, that should still be there otherwise... that's fine for me too. On 13.07.2013 16:01, WanMil wrote:
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
-- keep on biking and discovering new trails Felix openmtbmap.org & www.velomap.org
area_size() gives the area size on resolution 24. Your effects must have another reason. WanMil
Actually, after using it, I think it is checked for each resolution! I have some stuff disappearing at 23, that should still be there otherwise... that's fine for me too. On 13.07.2013 16:01, WanMil wrote:
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
WanMil <wmgcnfg@web.de> writes:
area_size() gives the area size on resolution 24. Your effects must have another reason.
Maybe the function should be garmin24_area() instead, then. I understand that it's good to have area in garmin units because that's the constraint this is intended to address, but this is confusing. Presumably there is also an area() that is in m^2, for people thinking in larger scales about logical size, not garmin units.
Am 20.07.2013 13:23, schrieb Greg Troxel:
WanMil <wmgcnfg@web.de> writes:
area_size() gives the area size on resolution 24. Your effects must have another reason. Maybe the function should be garmin24_area() instead, then. I understand that it's good to have area in garmin units because that's the constraint this is intended to address, but this is confusing.
Presumably there is also an area() that is in m^2, for people thinking in larger scales about logical size, not garmin units. I think it wouold be better to have a conversion in the documentation.
Henning
I think it wouold be better to have a conversion in the documentation.
Good idea. I have calculated some examples, how many m^2 are one garmin_unit^2. The conversion is dependent on the latitude value only (is this correct?): 1 garmin_unit^2 is: Latitude m^2 ==================== -85° 0,79 m^2 -80° 0,81 m^2 -75° 1,63 m^2 -70° 1,83 m^2 -65° 2,43 m^2 -60° 2,82 m^2 -55° 3,20 m^2 -50° 3,66 m^2 -45° 4,00 m^2 -40° 4,33 m^2 -35° 4,64 m^2 -30° 4,87 m^2 -25° 5,15 m^2 -20° 5,35 m^2 -15° 5,47 m^2 -10° 5,60 m^2 -5° 5,66 m^2 0° 5,71 m^2 5° 5,68 m^2 10° 5,61 m^2 15° 5,52 m^2 20° 5,35 m^2 25° 5,17 m^2 30° 4,93 m^2 35° 4,66 m^2 40° 4,36 m^2 45° 4,03 m^2 50° 3,66 m^2 55° 3,26 m^2 60° 2,85 m^2 65° 2,41 m^2 70° 1,95 m^2 75° 1,47 m^2 80° 0,99 m^2 85° 0,50 m^2 Having a look at the results I guess the procedure to calculate the area size in m^2 is wrong. I think results for lat=x° should equal lat=-x°? WanMil
Am 10.08.2013 13:21, schrieb WanMil:
I think results for lat=x° should equal lat=-x°?
This is what I would expect too. See attached ods-worksheet. $ro = 6371.0 //[km] $a = (90.0 - $lat1) * M_PI / 180.0; $b = (90.0 - $lat2) * M_PI / 180.0; $gamma = (abs($lon2 - $lon1)) * M_PI / 180.0; $c = $r0 * acos(cos($a)*cos($b) + sin($a)*sin($b)*cos($gamma)); //length [km] Henning
Hi, me again ;) Of course in the worksheet l is also in m, not in km. There are small differences between +/- lat because of calculating always the rectangle above the latitude. So the values below lat=0 are a little bit larger. Rounding may also have a influence. Henning
Hi,
I think results for lat=x° should equal lat=-x°?
Yes, simplified formula would be: area(latitude) = area_0*cos(latitude) There is something wrong with your calculations for negative values. Another problem. My first idea was to use area function to change small polygons into POI. Unfortunately area is not available for POI generated form polygons. I can calculate which polygons should be removed but I'm not able to find out which POI should be added. Maybe area function could be added to POI? -- Best regards, Andrzej
participants (5)
-
Andrzej Popowski -
Felix Hartmann -
Greg Troxel -
Henning Scholland -
WanMil