Data created with srtm2osm causes osm2navit to crash

[SlowRider]

srtm2osm is capable of converting srtm digital elevation contour data to osm data. I planned to use it in Navit as elevation contour lines. I know this is not what Navit was initially built but who cares :) . Navit is the right tool to have a nice hiking map on a mobile device.

Unfortunately osm2navit crashes while reading the osm file output by srtm2osm. It has a special option called "large" which is capable of processing larger areas by reducing memory consumption. Here are two files, one with the latter option set, one unset. Both will crash osm2navit:

​http://christeck.de/stuff/srtm_LargeOptionUnset.osm.tar.gz

​http://christeck.de/stuff/srtm_LargeOptionSet.osm.tar.gz

I have further reduced the problem. The following files have been created by reducing the above one resp. by creating one single way in josm and saving it to disc. Both cause the crash as well:

​http://christeck.de/stuff/srtm_reduced.osm.tar.gz

​http://christeck.de/stuff/srtm_josm.osm.tar.gz

[SlowRider]

The crash of osm2navit seems to belong to the node ref count of a way. A way may refer to a maximum of 24994 nodes, otherwise osm2navit will crash. Admittedly, such huge ways are rarely found. In this case, it's a height line of the black forest. Here's an example file which can be used to reproduce the problem. Just edit it in a text editor and reduce the amount of "nd ref"s by removing one single line, and osm2navit will do its job:

​http://christeck.de/stuff/Lat48Lon8Lat49Lon9_test.osm.tar.gz

It would be great if osm2navit could be adjusted to accept an increased amount of node refs per way. In the original version of the file mentioned above, the amount goes up to 31413. But I can imagine there are further files produced by srtm2osm which contain even more nodes per way.

I'll also ask the author of srtm2osm if such huge ways could be split.

[kazer]

osm2navit has been superseded by maptool. Please reopen if needed.