Chris Miller wrote:

It looks like there is a latitude value in your file that contains a large number of significant figures (far more than is actually required) and the parsing is failing on it. I just checked in a change that will hopefully solve the problem for you (r88) however I'd be interested in seeing the osm file that caused this problem. Is it possible to get a copy of your osm file?

srt2osm uses about 15dp and mixes node ids and way ids throughout the file. I came across this myself recently and so wrote the attached to reduce the data to 7dp and to place all the nodes before the ways. N.B. I am not a programmer in any sense of the word and this is my first and therefore only perl script so use at your own risk Cheers Paul

Chris Miller wrote:

Thanks Paul, that would explain it for sure. The problem Ralf hit was definitely a bug in the splitter though, I had made one too many assumptions in some custom code for parsing floating point numbers (Java's double parsing is very slow). I figured if the code could parse the planet file it could parse anything. Apparently not! :)

The mixture of node and way IDs should be OK as long as the --mixed parameter is specified for the splitter when it generates the cache. Using --mixed together with the fix I put in to r88 means there should be no need for your perl script. Once you have a cache generated, you can rerun the splitter as many times as you like without --mixed by using the (much faster) cache instead of the osm file. There's no need to even specify the osm file on the command line if you have a populated cache.

eg first run:

java -Xmx2000m splitter.jar --cache=cache/srtm_test --mixed --max-nodes=1200000 srtm_test.osm

Sorry Chris but unless I've missed something then..... paul@paul-pc:~/Maps/tile-splitter/splitter-r88/dist> java -jar splitter.jar --mapid=70020001 --cache=./ --mixed ../../../srtm2osm/Srtm2Osm-1.7.10.0/fullukcontours.osm Time started: Wed Sep 09 11:48:04 BST 2009 mapid = 70020001 cache = ./ Checking for an existing cache and verifying contents... No suitable cache was found. A new cache will be created to speed up the splitting stage Map is being split for resolution 13: - area boundaries are aligned to 0x800 map units - areas are multiples of 0x1000 map units wide and high Processing ../../../srtm2osm/Srtm2Osm-1.7.10.0/fullukcontours.osm Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException: 19 at uk.me.parabola.splitter.Convert.parseDouble(Convert.java:171) at uk.me.parabola.splitter.OSMParser.startNode(OSMParser.java:138) at uk.me.parabola.splitter.OSMParser.startElement(OSMParser.java:98) at uk.me.parabola.splitter.AbstractXppParser.parse(AbstractXppParser.java:42) at uk.me.parabola.splitter.Main.processOsmFiles(Main.java:346) at uk.me.parabola.splitter.Main.processMap(Main.java:335) at uk.me.parabola.splitter.Main.calculateAreas(Main.java:240) at uk.me.parabola.splitter.Main.split(Main.java:148) at uk.me.parabola.splitter.Main.main(Main.java:93) The input file is 3.9GB if that helps and r88 runs against the very small test file I created when testing my script. If you need any other info just ask. Cheers Paul

Chris Miller wrote:

Hi Paul,

I'd used Ralf's osm file as a test case to solve this problem, but seems like even that didn't go far enough. I have no idea why but the numbers in your file contain several digits more precision than a 64bit floating point number can even represent. I've added another check so that any digits beyond what is sane are now safely ignored. Sorry for the trouble and thanks for letting me know. It should be solid now but if you still have a problem please send through your test file and I'll take another look.

Chris

That did the trick. Whilst running I received quite a few of the following Node encountered with missing data. Bad/corrupt osm file? id=1000446803, lat=52.552916666666668, lon=null. Ignoring this node Examination of this node reveals that the data is indeed corrupt as it has no longitude value:- <node id="1000446803" lat="52.552916666666668" /> Cheers Paul

Chris Miller wrote:

Heh, you're doing a great job testing various corner-cases in the splitter - keep up the good work :) I have to wonder quite how that osm file you have was generated though. Are there really nodes in the osm database that are missing lat and/or lon values? Seems a bit worrying if so.

The data isn't from the OSM database it's generated by srtm2osm which takes a bbox and generates contour lines within that bbox from NASAs data so the fault really lies within that Cheers Paul

Hi On 10/09/09 05:04, Apollinaris Schoell wrote:

I have a large lake with a relation connecting all ways together. It seems mkgmap creates a polygon for each of the ways by connecting start and end together. Do we have support for multipolygons. In this case 2 arms of the lake cross the tile boundary. the 2 arms are rendered correct in the next tile but the main part of the lake is a complete mess. it looks like the relation is completely ignored.

There is support for multi-polygons. There is much better version in the multipolygon branch with loads of fixes. I think that has had some reasonable testing so I shall merge the multipolygon fixes to trunk. ..Steve

On 12/09/09 21:42, Dermot McNally wrote:

...

I think that has had some reasonable testing so I shall merge the multipolygon fixes to trunk.

Oh goody. Isn't the sea polygon support on that branch too? Will they be merged too?

Yes it is, but it requires java 1.6 so it will be merged separately after I've given a bit of notice. ..Steve

On 12/09/09 23:30, Apollinaris Schoell wrote:

this branch fixes the polygon in one tile. big improvement! here is a tricky small example where it still fails when split into 2 tiles. http:/apo42.dyndns.org/shastalake.tgz

That appears to be a good test case. I had to remove the bounds element as that just selects a tiny area within the lake, but then the whole lake could be seen when compiling the un-splitted file. After splitter is run then the 18800010.img file does not look good, although JOSM shows the lake fairly well. ..Steve

I don't care so much about efficiency if the results are better. if we can't support it maybe it's better to drop incomplete polygons. You asked earlier for some other relation question. I would say a maximum of 3 levels is just good enough. Also you have to be careful of loops. Relations can contain other relations and even themselves. for map making most are not really important since they are just collections and have no useful tags for a garmin map. as an example I use it to have all ways and relations of an import in a single relation. On 13 Sep 2009, at 12:21 , Chris Miller wrote:

I've grabbed a copy of this test case and when I find the time will see what can be done about it in the splitter. It sounds like it might be quite a tricky problem to solve efficiently though.

SR> On 12/09/09 23:30, Apollinaris Schoell wrote: SR>

...

...

this branch fixes the polygon in one tile. big improvement! here is a tricky small example where it still fails when split into 2 tiles. http:/apo42.dyndns.org/shastalake.tgz SR> That appears to be a good test case. SR> SR> I had to remove the bounds element as that just selects a tiny area SR> within the lake, but then the whole lake could be seen when SR> compiling the un-splitted file. SR> SR> After splitter is run then the 18800010.img file does not look good, SR> although JOSM shows the lake fairly well. SR> SR> ..Steve SR>

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

On 14 Sep 2009, at 13:19 , Steve Ratcliffe wrote:

On 13/09/09 20:21, Chris Miller wrote:

...

I've grabbed a copy of this test case and when I find the time will see what can be done about it in the splitter. It sounds like it might be quite a tricky problem to solve efficiently though.

To me it seems that splitter is doing OK with it. If the multipolygon code could detect the missing ways and just join up the two loose ends I think it would work. As I said josm seems to deal with it OK.

Couldn't find a solution for this problem. You can always close the 2 ends in 2 ways. shortest connection or around the tile boundary which will result in an inverted polygon. JOSM seems to connect all ways first and draw the fill from start to end node. will be correct in most cases but not 100%

Of course if splitter could do something that would be great.

..Steve

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