Hi Philip >From the traceback it looks like an area is being split into an excessive >number of subdivisions. Masking the first exception won't help produce a reasonable map.
Worth trying is to put back the -ea option and try option --order-by-decreasing-area which changes the behaviour the splitting algorithm. I've never looked at how contours work: eg. where the data comes from and how it is merged into the map generation process. Can you briefly explain your process and send your splitter & mkgmap options and, if not using the default style, your style. I'll see what I can do. Ticker On Fri, 2025-09-19 at 13:53 +0200, Philip Homburg via mkgmap-dev wrote: > > In the short term, try removing the -ea option from your java > > command. This should stop this crash but the part of resultant map > > might be rubbish or the bit might be not noticeable. I'll have a > > look sometime to see if I can work out why it is generating a value > > that won't fit into the allocated #bits in the .img file. > > I tried that on one the pbf files that came out of the splitter and that > seemed fine. Then I tried it on the entire collection. I first got > a failure that 8GB memory was not enough. So made it 16GB. But now > it seems to be stuck in a loop. > > If you need any help reproducing the problem then please let me know. > _______________________________________________ > mkgmap-dev mailing list -- [email protected] > To unsubscribe send an email to [email protected] > %(web_page_url)slistinfo/%(_internal_name)s _______________________________________________ mkgmap-dev mailing list -- [email protected] To unsubscribe send an email to [email protected] %(web_page_url)slistinfo/%(_internal_name)s
