On 12 Feb 2010, at 7:17 , Chris Miller wrote:
FH> The problem seems to me, that if a tile has more max-nodes, then a FH> very FH> dense city (like Athens, Melbourne, ...) in an otherwise rather FH> empty FH> area (huge tile) will crash. For Athens I had to go as low as FH> 600.000, FH> for Melbourne 800.000 was fine. FH> 1.600.000 is definitely not only crashing a few tiles, but in my FH> eyes FH> around 10% of European tiles.
One thing that is clear is that the limiting factor isn't really the number of nodes in a tile; more likely it's limited by the number (and type?) of ways or relations, or some combination thereof. This is a very difficult (expensive) calculation to perform however when trying to determine where the tile boundaries should fall, so the number of nodes is used as a fairly rough approximation instead. Of course even if there was an efficient way to subdivide based on way/relation counts, we still don't currently know what the rules should be that determine the limits for each tile.
to make it even more complicated mkgmap can optimize ways with too many nodes. some imports like Massgis didn't reduce point density. node count in this places will be huge for no benefit in accuracy. optimizing ways can help a lot but how could splitter consider that mkgmap can throw away >50% of all nodes easily another problem in osm data is the number of unused nodes, mainly caused by server/network problems during imports.
Chris
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev