Hi Andrzej, seems that the garmin data is older. Reg. polygon optimization: When I started to implement that, I noticed problems with buildings that share lines. Sometimes the lines were moved apart because the algo optimized one poly after the other. So I started to code that ShapeMergeFilter which connects the polygon and removes points where possible. The open problem now is that I merge the polys of each sub division. If I optimize them, I see again the "move apart" problem at places where one poly is in one sub div and another neighbour poly is in a different sub div. Maybe I can implement an algo that optimizes at least those polygons which can't share any points with others in other sub divisions with some kind of reference counter. The correct solution that I have in mind requires a big change in data structures, so I'd like to postpone that because I want to merge the branch to trunk first. Gerd popej wrote
Hi Gerd,
Are you also satisfied with the results?
Sure, thanks. Railways look good.
I'm a bit worried about inconsistency. See this building: http://www.openstreetmap.org/way/256598227
I have attached screenshot building-mkgmap.png. On my map this building is drawn as an outline and a polygon. I know that other people use this kind of presentation too. I would preffer similar simplification for polygons.
See building-garmin.png. Garmin is using more extreme simplification, maybe even dedicated algorithm for buildings.
-- Best regards, Andrzej
_______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
building-mkgmap.png (20K) <http://gis.19327.n5.nabble.com/attachment/5796805/0/building-mkgmap.png>; building-garmin.png (17K) <http://gis.19327.n5.nabble.com/attachment/5796805/1/building-garmin.png>;
-- View this message in context: http://gis.19327.n5.nabble.com/Distorted-lines-tp5775761p5796807.html Sent from the Mkgmap Development mailing list archive at Nabble.com.