[mkgmap-dev] bugreport for new splitter

Sun Aug 9 21:58:04 BST 2009

OK I've isolated the secondary problem and checked in a fix. Subtle bug, 
I was using a 1 (int) instead of a 1L (long) during some bitshifting and 
was suffering from overflow in certain situations. Sorry for any trouble 
this bug may have caused, hopefully it's all working now as I'd originally 
intended.

One thing I noted during the testing of this fix is that setting max-nodes=300000 
for europe.osm triggers a lot of "Node in too many areas" warnings, due to 
a fair number of nodes ending up in 5+ areas. I can partially or even completely 
fix this as long as the number of nodes suffering from this doesn't get too 
high (otherwise memory usage will go through the roof).

"Partially fix" = nodes get written to all 5+ areas correctly but ways/rels 
only see 4 of the node's areas. No memory impact, very minor performance 
impact. Could print warnings about the affected nodes.
"Completely fix" = nodes/ways/rels see all areas a node belongs to even if 
it's 5+. Slightly higher but still small performance impact, memory impact 
depends on the number of nodes in > 4 areas. If there are a lot of these 
nodes (say 1x10^5), memory starts taking quite a big hit (100s of MB).

What are people's thoughts on this? Perhaps we'd just be better off recommending 
to increase --max-nodes until the problem goes away? Or I could cap the number 
of nodes that are allowed to be in 5+ areas, then start printing warnings? 
All comments appreciated, I don't have a lot of experience with how this 
might benefit/adversely affect mkgmap.

Chris

> Hmm, running with max-nodes=300000 on r65 now makes it further, but
> fails with another (related) problem. I'm going to try and find the
> problematic way(s)/relation(s) so I can make a test case. Please hold
> off on big splits with r65 for now.