On 01/03/2010 12:41 AM, Felix Hartmann wrote:

Best provide all the info. Style (try to replace against default to see if it still crashes Mapsource), otherwise cut it down to find the problematic line, upload the *.img it crashes on (watch out if there are several displayed) somewhere, and try with different overview map

OK, I tried to narrow this down. It looks a bit weird though. The problem doesn't seem to be connected to one feature, tag or element. It looks like it's a sort of overflow, like some maximum number has been exceeded. My minimum config to recreate the problem: The command line: /usr/java/jre1.6.0_16/bin/java -jar mkgmap-r1455/mkgmap.jar --latin1 --family-id=1331 --product-id=1 --style-file=mkgmap-style-topotest/ --tdbfile=yes --remove-short-arcs 10000040.osm.gz The style consist of: - no relations file - no polygons file The options file is: levels = 0:24,1:23,2:22,3:21,4:20,5:18,6:16,7:14 The points file has just one line: place=hamlet [0x1100 level 4] The lines file looks like this: highway=unclassified [0x06 road_class=1 road_speed=2 level 3] highway=tertiary [0x05 road_class=1 road_speed=3 level 3] highway=secondary [0x04 road_class=2 road_speed=3 level 4] highway=primary [0x03 road_class=3 road_speed=4 level 5] highway=cycleway [0x16 road_class=0 road_speed=1 level 2] highway=pedestrian [0x06 road_class=1 road_speed=2 level 3] highway=residential [0x06 road_class=0 road_speed=2 level 3] highway=footway [0x16 road_class=0 road_speed=0 level 3] highway=service [0x07 road_class=0 road_speed=2 level 3] highway=track [0x0a road_class=0 road_speed=1 level 3] highway=path [0x16 road_class=0 road_speed=1 level 3] highway=living_street [0x06 road_class=0 road_speed=1 level 3] If I remove any one of these lines from the points or lines file the problem disappears. If I remove the road_class and road_speed definitions from e.g. unclassified the problem disappears. If I move e.g. the pedestrians into level 4 or 7 the problem persists. The OSM file is one tile made with the mkgmap splitter from the Geofabrik Europe file, it can be found here: http://www.kleineisel.de/ralf/gps/10000040.osm.gz Any ideas? Something more I can test?

On 01/06/2010 09:26 PM, Mark Burton wrote:

Enable assertions - that may catch some overflow or other problem that is causing a corrupt map to be generated.

This gives me this message: NET 1 offset too large at (Leigraaf, http://www.openstreetmap.org/browse/way/6890957) Looks like what others reported in november. I must have hit some limit and will have to split some of my tiles. Sorry for the noise.

Why anyone would use the development version of mkgmap (or even a stable version) without having assertions enabled beats me.

Probably because: - the docs don't mention it - the wiki doesn't mention it - it worked so great without for the last 1.5 years :-)

It's a great shame that we can't enable assertions by default.

Just looked at the java docs and found the following: Programmers of certain critical systems might wish to ensure that assertions are not disabled in the field. The following static initialization idiom prevents a class from being initialized if its assertions have been disabled: static { boolean assertsEnabled = false; assert assertsEnabled = true; // *Intentional side effect!!!* if (!assertsEnabled) throw new RuntimeException("Asserts must be enabled!!!"); }

On 06/01/10 20:59, Ralf Kleineisel wrote:

...

Why anyone would use the development version of mkgmap (or even a stable version) without having assertions enabled beats me.

Probably because: - the docs don't mention it - the wiki doesn't mention it - it worked so great without for the last 1.5 years :-)

Well that error shouldn't be an assertion anyway. Assertions are for catching invalid assumptions and bugs, but this is not a bug, it can't be simply fixed, so there should just be a regular message like every other overflow. I will do it. ..Steve