polygon-size-limit inside polygons file - large work to implement?
Well I recently noticed, that some super detail mappers, started to map landuse=grass or leisure=garden for supersmall areas. E.g. a 2x4m private garden, or a 1mx10m long strip between both sides of a road. Yuck.... I would prefer to keep my maps clean, and get rid of that garbage. Could there be a polygon-size-filter that works also for resolution=24, and that can be setup much more aggressive? Especially for gardens and grass, I don't need small private ones, but would like to keep big public gardens and grassfields. So could there be an implementation like the following for the polygons file: {set mkgmap:polygon-size-limit=24:30 ; 23:20 ; 22:15 ..} which overrides the default setting? That would be absolutely great for combating all the micromapping junk! -- keep on biking and discovering new trails Felix openmtbmap.org & www.velomap.org
I would prefer a style-function like we have already for length of ways. Eg. called polygon-size and returns the size in m². I think this is not much more work, but it is a lot more flexible. Henning Am 10.07.2013 17:21, schrieb Felix Hartmann:
Well I recently noticed, that some super detail mappers, started to map landuse=grass or leisure=garden for supersmall areas. E.g. a 2x4m private garden, or a 1mx10m long strip between both sides of a road. Yuck....
I would prefer to keep my maps clean, and get rid of that garbage. Could there be a polygon-size-filter that works also for resolution=24, and that can be setup much more aggressive? Especially for gardens and grass, I don't need small private ones, but would like to keep big public gardens and grassfields.
So could there be an implementation like the following for the polygons file: {set mkgmap:polygon-size-limit=24:30 ; 23:20 ; 22:15 ..} which overrides the default setting?
g. called polygon-size That would be absolutely great for combating all the micromapping junk!
I have an implementation of such a style function. It is based on the algorithm described here: http://forum.worldwindcentral.com/showthread.php?t=20724 But I don't know about the license and therefore I wonder if I can commit that. WanWil
I would prefer a style-function like we have already for length of ways. Eg. called polygon-size and returns the size in m². I think this is not much more work, but it is a lot more flexible.
Henning
Am 10.07.2013 17:21, schrieb Felix Hartmann:
Well I recently noticed, that some super detail mappers, started to map landuse=grass or leisure=garden for supersmall areas. E.g. a 2x4m private garden, or a 1mx10m long strip between both sides of a road. Yuck....
I would prefer to keep my maps clean, and get rid of that garbage. Could there be a polygon-size-filter that works also for resolution=24, and that can be setup much more aggressive? Especially for gardens and grass, I don't need small private ones, but would like to keep big public gardens and grassfields.
So could there be an implementation like the following for the polygons file: {set mkgmap:polygon-size-limit=24:30 ; 23:20 ; 22:15 ..} which overrides the default setting?
g. called polygon-size That would be absolutely great for combating all the micromapping junk!
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
what's the difference? The polygon size limit is not m² but garmin units. So it should be fine too, or not? Does it matter so much, that extreme North/South this is different (I don't even know if it is). length filter is great, but not so fast (dunno if that is only if you use it in conjuction with routes), and there was no option. The polygon-size filter already exists - so it would merely be specifying it further (without any speed reductions I would believe). Or because m² is easier to setup? I'm not sure - if there are any benefits. One would need to play around a bit with it anyhow, to find out sensible values. So be it Garmin units, or metric units, doesn't make a difference for me. On 10.07.2013 20:00, Henning Scholland wrote:
I would prefer a style-function like we have already for length of ways. Eg. called polygon-size and returns the size in m². I think this is not much more work, but it is a lot more flexible.
Henning
Am 10.07.2013 17:21, schrieb Felix Hartmann:
Well I recently noticed, that some super detail mappers, started to map landuse=grass or leisure=garden for supersmall areas. E.g. a 2x4m private garden, or a 1mx10m long strip between both sides of a road. Yuck....
I would prefer to keep my maps clean, and get rid of that garbage. Could there be a polygon-size-filter that works also for resolution=24, and that can be setup much more aggressive? Especially for gardens and grass, I don't need small private ones, but would like to keep big public gardens and grassfields.
So could there be an implementation like the following for the polygons file: {set mkgmap:polygon-size-limit=24:30 ; 23:20 ; 22:15 ..} which overrides the default setting?
g. called polygon-size That would be absolutely great for combating all the micromapping junk!
-- keep on biking and discovering new trails Felix openmtbmap.org & www.velomap.org
Am 10.07.2013 20:13, schrieb Felix Hartmann:
what's the difference?
Hi, the unit isn't the real difference. If it's easyer to calculate Garmin-units² it would also be ok. The difference between our the proposals is: In my proposal you get the polygon-size as a value and can handle it in style. So for example you can also avoid a much to large building or so. (Maybe you remeber the very large Aldi-supermarket some month ago.) In you proposal it would only be possible to remove small polygons. Henning
well as for your proposal - the same could be achieved by addind a function like {set mkgmap:polygon-size-max-limit=24:300000 ; 23:200000 ; 22:150000 ..} and then there is no need to calculate the size in m². Especially if you want to use this for checking against broken polygons regulary, you will need to basically add sensible values for each of your lines in the polygon file - hence that will need quite a bit of computation time, and then using some data existing should be much quicker then first calculating this number. I did not plan to use this widespread - just for certain polygon types that are very often used for micromapping (and micromapping is a thing I rather omit, sadly people go f*ck crazy in Vienna, mapping all boardwalks, rubbish bins, gullies and even indoor ways of every floor of public buildings in some universities. - due to garmin units precision this already means no more straight streets at intersections and similar problems) On 10.07.2013 20:36, Henning Scholland wrote:
Am 10.07.2013 20:13, schrieb Felix Hartmann:
what's the difference?
Hi, the unit isn't the real difference. If it's easyer to calculate Garmin-units² it would also be ok. The difference between our the proposals is: In my proposal you get the polygon-size as a value and can handle it in style. So for example you can also avoid a much to large building or so. (Maybe you remeber the very large Aldi-supermarket some month ago.) In you proposal it would only be possible to remove small polygons.
Henning
-- keep on biking and discovering new trails Felix openmtbmap.org & www.velomap.org
participants (3)
-
Felix Hartmann -
Henning Scholland -
WanMil