Mark, yes I can do. But before we start huge debugging. I found out, that these file were bigger then 20 MB. Could this be a limitation of mkgmap? I recreated the maps with low "max-nodes" in splitter, the file became smaller and it works, now. Is there a know issue? Marco Mark Burton wrote:

Hi Marco,

...

I'm using mkgmap very often and meanwhile it's working really good, but I found something, that some img files are broken. After integrating it into Mapsource, MS is crashing with an error xxxxxxxxxx.img has an broken record. How can I help you to find the problem? What do you nedd to find this issue?

Error message, img file, my mkgmap commandline options. Something else? May I send this to the mailinglist?

A sample broken img file to look at would be a good start.

Can you put it on a web server so I can download it?

Cheers,

Mark _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Mark, Yes I know that it's experimental software. I asked for known issues concerning a file size over 20MB? No I do not use assertion. Do you still need the map file, or shall I rebuild the maps with assertion first? Marco Mark Burton wrote:

Hi Marco,

...

yes I can do. But before we start huge debugging. I found out, that these file were bigger then 20 MB. Could this be a limitation of mkgmap? I recreated the maps with low "max-nodes" in splitter, the file became smaller and it works, now. Is there a know issue?

There's always known issues - it is experimental software that's in a constant state of development.

You are building your maps with Java assertions enabled aren't you? You should always have them enabled for mkgmap. If you were not using assertions, please rebuild the failing map with them enabled and see if it reports any errors.

Cheers,

Mark _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Okay Thanks Marco Mark Burton wrote:

Hi Marco,

...

Yes I know that it's experimental software. I asked for known issues concerning a file size over 20MB? No I do not use assertion. Do you still need the map file, or shall I rebuild the maps with assertion first?

Yes, please rebuild with assertions enabled and see if you get any error messages.

Cheers,

Mark _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

On 09-10-30 18:47:07 CET, dom wrote:

I tried it out again with assertions and I got the following error.

Doing europe.osm map now... java.lang.AssertionError: NET 1 offset too large at uk.me.parabola.imgfmt.app.net.RoadDef.writeRgnOffsets(RoadDef.java:322)

i get the same error, with two different combinations of splitter and mkgmap. i've cut a bbox (left=5.5 bottom=46.5 right=15 top=55, that's roughly DE and AT) from the last planet.osm using osmosis 0.30. the assertion fails with both - splitter r97 and mkgmap trunk r1334 - splitter r74 and mkgmap trunk r1144 + sea5 patch the latter worked fine before with other large bbox excerpts from older planets. producing maps from smaller extracts works fine with both combinations. the splitter was given a --max-nodes=1000000. any ideas? rj

On 09-10-31 17:10:19 CET, dom Team OiD wrote:

Yes,

and it's always the same tile. It's a part of netherlands.

it may be the same data, as my bbox surrounding germany includes the eastern half of the netherlands. can you give me the tile's bbox coordinates? with both your and my tile's bbox coordinates, the intersection of them is likely to contain the data that triggers the bug...? rj

On 09-10-31 18:24:41 CET, Mark Burton wrote:

This looks to me that there is simply too many roads in the tile. Can you tell the splitter to limit the number of ways in a tile?

unfortunately the splitter does not seem to offer that option, it seems that one can only limit the number of nodes. but your diagnosis looks rather likely: i've counted the number of ways in the tiles: % for f in *.osm.gz; do echo -n "$f ";zcat $f|egrep '^<way'|wc -l;done 63250345.osm.gz 41122 63250346.osm.gz 72991 63250347.osm.gz 25464 63250348.osm.gz 95598 63250349.osm.gz 118770 63250350.osm.gz 48855 63250351.osm.gz 108894 63250352.osm.gz 103495 63250353.osm.gz 39503 63250354.osm.gz 78059 63250355.osm.gz 97869 63250356.osm.gz 105851 63250357.osm.gz 177632 63250358.osm.gz 76355 63250359.osm.gz 146213 63250360.osm.gz 196410 63250361.osm.gz 138871 63250362.osm.gz 34978 63250363.osm.gz 36015 63250364.osm.gz 84189 63250365.osm.gz 112878 63250366.osm.gz 57585 63250367.osm.gz 34210 63250368.osm.gz 63015 63250369.osm.gz 37611 63250370.osm.gz 60976 63250371.osm.gz 93238 63250372.osm.gz 125751 63250373.osm.gz 173999 63250374.osm.gz 84054 63250375.osm.gz 84722 63250376.osm.gz 57448 63250377.osm.gz 81780 63250378.osm.gz 56650 63250379.osm.gz 55699 63250380.osm.gz 99090 63250381.osm.gz 124650 63250382.osm.gz 181411 63250383.osm.gz 95862 63250384.osm.gz 191424 63250385.osm.gz 101558 63250386.osm.gz 177383 63250387.osm.gz 98071 63250388.osm.gz 114368 63250389.osm.gz 220462 63250390.osm.gz 221984 63250391.osm.gz 147777 63250392.osm.gz 161310 63250393.osm.gz 104321 63250394.osm.gz 143020 63250395.osm.gz 140887 63250396.osm.gz 99034 63250397.osm.gz 99601 63250398.osm.gz 87391 63250399.osm.gz 112557 63250400.osm.gz 61758 63250401.osm.gz 103510 63250402.osm.gz 55007 63250403.osm.gz 107685 63250404.osm.gz 101004 63250405.osm.gz 80947 63250406.osm.gz 111689 63250407.osm.gz 91736 63250408.osm.gz 136023 63250409.osm.gz 154482 63250410.osm.gz 82710 63250411.osm.gz 146946 63250412.osm.gz 130475 63250413.osm.gz 112491 with your changed assertion output... java.lang.AssertionError: NET 1 offset too large at (http://www.openstreetmap.org/browse/way/6926238) (a pretty short way, btw, just five nodes) ...it was easy to find the problematic tile: % zegrep "^<way id='6926238'" *.osm.gz 63250389.osm.gz:<way id='6926238'> it's the tile with 220462 ways! rj

I had the same problem with the netherlands coutry map and europe. Teh europe map failed at the same koords like the netherland. So this tile must have any information which causes ths error. A reduction of nodes of the splitted tiles helped to solve the problem for the netherlands map, but not fore europe. Currenty I'm running a build ad reduced the nodenum to 600000. I will post the result. Marco Mark Burton schrieb:

Hi Robert,

...

it's the tile with 220462 ways!

Yes but tile 63250390 has even more ways so it's not the number of ways that matters (directly) but how much stuff is output for each way.

For each way, its name(s), info about what levels it appears in and address information is output. All of this is variable length so you can't really predict when it will reach the overflow threshold.

So if you set the limit at X ways, some maps would be OK but others would fail depending on whether lots of ways had long names or address info specified.

Not sure how to solve this one at the moment.

Cheers,

Mark _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

On 01/11/09 12:37, dom Team OiD wrote:

But I updated the source to the latest version and about 60% of the maps do not show any data. They are empty, or borken. Mapsource show "overzoomed" at 150km zoom and the files have normal size. But they show nothing.

One other question, a new tdb file appeared. And how do I activate the mdr creation?

These are probably related, the names for the tdb and overview map are now by default osmmap.tdb and osmmap.img. Missing maps are usually caused by using mismatched overview and/or tdb files. You will need to use them rather than the old ones. If you want the old names you can give the option --overview-mapname=63240000 The documentation says that the default name is OSM_map so I will change that. ..Steve