DP Filter and areas at Resolution=24

Could the DP Filter not remove any points at resolution=24? Or is there another reason why many small polygons like buildings get mashed? In most cases there are not even any reductions in points needed to draw the areas. mkgmap: vs mapnik:

Hi Felix,
Could the DP Filter not remove any points at resolution=24?
It doesn't do anything at that res.
Or is there another reason why many small polygons like buildings get mashed?
Yes, the reason is that the coordinates round to approx the nearest 2m. We can't do anything about that, it's what Garmin support.
In most cases there are not even any reductions in points needed to draw the areas.
Agreed. Cheers, Mark

Mark Burton wrote:
Hi Felix,
Could the DP Filter not remove any points at resolution=24?
It doesn't do anything at that res.
Or is there another reason why many small polygons like buildings get mashed?
Yes, the reason is that the coordinates round to approx the nearest 2m. We can't do anything about that, it's what Garmin support.
okay I see. So the only real solution would be to have intelligent filters moving the nodes to nearest 2m in such a way that there is minimal loss of detail. Probably pretty CPU intensive and a lot of work. So we have to live with it, in most places there is no real loss of information anyhow.
In most cases there are not even any reductions in points needed to draw the areas.
Agreed.
Cheers,
Mark _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Felix Hartmann schrieb:
Mark Burton wrote:
Hi Felix,
Could the DP Filter not remove any points at resolution=24?
It doesn't do anything at that res.
At the moment it does nothing, but I'm not sure, if it SHOULD do something at this level, as there may be well some points to delete.
Yes, the reason is that the coordinates round to approx the nearest 2m. We can't do anything about that, it's what Garmin support.
okay I see. So the only real solution would be to have intelligent filters moving the nodes to nearest 2m in such a way that there is minimal loss of detail. Probably pretty CPU intensive and a lot of work. So we have to live with it, in most places there is no real loss of information anyhow. I have thought of some ways to merge the rounding filter and the dp filter for this reason. Mabe the dp filter should take into account the distance to rounded coordinates, not the real one. Or maybe it would be better to insert the rounding filter AFTER the dp filter. It may be possible to achive a little improvement, but I doubt it. The main reason is the limitation of resolution to 2m.
Regards, Johann

One idea for rounding at that level: Most annoying is that rectangles that are buildings aren't rectangles anymore after rounding. As the OSM data in itself probably isn't accurate at the 2 m level perhaps we could do "tweak" the coordinates so that rectangles stay rectangles (I know, the projection has an influence as well)? This would make the maps much better looking. Any thoughts about that? Regards Thilo Am 26.11.2009 um 11:47 schrieb Johann Gail:
Felix Hartmann schrieb:
Mark Burton wrote:
Hi Felix,
Could the DP Filter not remove any points at resolution=24?
It doesn't do anything at that res.
At the moment it does nothing, but I'm not sure, if it SHOULD do something at this level, as there may be well some points to delete.
Yes, the reason is that the coordinates round to approx the nearest 2m. We can't do anything about that, it's what Garmin support.
okay I see. So the only real solution would be to have intelligent filters moving the nodes to nearest 2m in such a way that there is minimal loss of detail. Probably pretty CPU intensive and a lot of work. So we have to live with it, in most places there is no real loss of information anyhow. I have thought of some ways to merge the rounding filter and the dp filter for this reason. Mabe the dp filter should take into account the distance to rounded coordinates, not the real one. Or maybe it would be better to insert the rounding filter AFTER the dp filter. It may be possible to achive a little improvement, but I doubt it. The main reason is the limitation of resolution to 2m.
Regards, Johann _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

One idea for rounding at that level:
Most annoying is that rectangles that are buildings aren't rectangles anymore after rounding. As the OSM data in itself probably isn't accurate at the 2 m level perhaps we could do "tweak" the coordinates so that rectangles stay rectangles (I know, the projection has an influence as well)? This would make the maps much better looking.
Any thoughts about that?
Just thinking about it: For lines the rounding is simply done by setting the coord to the nearest garmin unit by distance. For polygons (and maybe even for lines) not the nearest garmin unit should be choosen, but the garmin unit, which has the smallest changes to the angle. So the least influence to the outline should be achieved. An possible algorithm could be: foreach point in the polygon do: calculate the real angle (with unrounded coords!) round coordinates to the upper left garmin unit, calculate angle a1 round coordinates to the lower left garmin unit, calculate angle a2 round coordinates to the upper right garmin unit, calculate angle a3 round coordinates to the lower right garmin unit, calculate angle a4 choose the coordinate with the least difference to the real angle.
participants (4)
-
Felix Hartmann
-
Johann Gail
-
Mark Burton
-
Thilo Hannemann