Bogus warnings about intersected ways in multipolygons
I am getting these for yesterday's finland.osm.bz2 and mkgmap r1499. I suspect that these are coming from the branches/mp merge: SEVERE (MultiPolygonRelation): Multipolygon http://www.openstreetmap.org/browse/relation/5828 contains intersected ways This relation or the containing points have not been changed recently. It looks OK to me. It would be nice if the message gave a point where mkgmap thinks that the ways are intersecting, like this: "Multipolygon .../relation/5828 contains intersected ways at http://www.openstreetmap.org/?mlat=60.1604765&mlon=24.9544602&zoom=18" (I am just picking a random node in the above building multipolygon). I still can't view the gmapsupp.img because of a NullPointerException: ... SEVERE (MultiPolygonRelation): Multipolygon http://www.openstreetmap.org/browse/relation/301046 contains intersected ways SEVERE (MultiPolygonRelation): Multipolygon http://www.openstreetmap.org/browse/relation/341061 contains intersected ways Exception in thread "main" java.lang.NullPointerException at uk.me.parabola.tdbfmt.OverviewMapBlock.setArea(OverviewMapBlock.java:100) at uk.me.parabola.mkgmap.combiners.TdbBuilder.addToTdb(TdbBuilder.java:114) at uk.me.parabola.mkgmap.combiners.TdbBuilder.onMapEnd(TdbBuilder.java:103) at uk.me.parabola.mkgmap.main.Main.endOptions(Main.java:370) at uk.me.parabola.mkgmap.CommandArgsReader.readArgs(CommandArgsReader.java:124) at uk.me.parabola.mkgmap.main.Main.main(Main.java:122) Best regards, Marko
Hi Marko
I still can't view the gmapsupp.img because of a NullPointerException:
I can only think that this is due to an img that has failed to build properly. I saw one case of this was using the command line option --keep-going, are you using that? If so remove it and see if the error is more obvious. I am just about to commit a small change that will prevent .img files without a TRE section being classified as an IMG file. ..Steve
On Tue, Jan 19, 2010 at 10:20:38AM +0000, Steve Ratcliffe wrote:
Hi Marko
I still can't view the gmapsupp.img because of a NullPointerException:
I can only think that this is due to an img that has failed to build properly. I saw one case of this was using the command line option --keep-going, are you using that? If so remove it and see if the error is more obvious.
No, I am not using --keep-going, and I am running java -ea.
I am just about to commit a small change that will prevent .img files without a TRE section being classified as an IMG file.
The r1501 fixed it. But why was no TRE section generated by mkgmap in the first place? Will it do any harm if it is missing? Or was the TRE section generated in the wrong place? I am using --max-jobs on a dual core processor. I did not try without that. Marko
On Tue, Jan 19, 2010 at 12:42:46PM +0200, Marko Mäkelä wrote:
The r1501 fixed it. But why was no TRE section generated by mkgmap in the first place? Will it do any harm if it is missing? Or was the TRE section generated in the wrong place? I am using --max-jobs on a dual core processor. I did not try without that.
Something is seriously wrong, because the gmapsupp.img is 17M instead of the usual 44M. The input is 67M in bzip2 format. Did the new multipolygon code dry up all lakes? No, it seems that the southmost tile (which is the largest by size) was dropped. My scripts are at http://www.polkupyoraily.net/osm/. Next, I will retry it with --max-jobs=1 and after that, moving the tile boundaries, in case the southern tile has grown too large. But why didn't I see any warning or assertion for that? Marko
The r1501 fixed it. But why was no TRE section generated by mkgmap in the first place? Will it do any harm if it is missing? Or was the TRE section generated in the wrong place? I am using --max-jobs on a dual core processor. I did not try without that.
Yes the 1501 patch will drop any file that does not have a TRE section from the TDB. A missing TRE file means that the .img is useless. Now you should know which .img(s) is/are faulty by looking at which are missing from the gmapsupp. I am attempting to reproduce from your script. ..Steve
I am attempting to reproduce from your script.
OK I have reproduced the problem. It appears that the directory withing the IMG is empty and yet the file is quite large, so something is very wrong. $ jv test.ListFile 63240001.img Block size: 512 . 0 I don't see the problem without --route, but do see it compiling '0001.osm.gz with it separately by itself. Probably something is on the edge of overflowing within the file. It should look something like $ jv test.ListFile 63240002.img Block size: 512 . 44032 63240002.RGN 6579328 63240002.TRE 14329 63240002.LBL 161801 63240002.NET 778788 63240002.NOD 2102966 ..Steve
Hi Steve,
I am attempting to reproduce from your script.
OK I have reproduced the problem. It appears that the directory withing the IMG is empty and yet the file is quite large, so something is very wrong.
Can you add some diagnostics for this case? Preferrably near the place where the overflow is about to occur. It would also be nice if mkgmap complained about the missing TRE header. Currently it is omitting the offending tile without warning. I got it to work by moving the tile border south from lat=2916352 to lat=2899968: -rw-r--r-- 1 marko marko 26660864 19.1. 13:45 63240001.img -rw-r--r-- 1 marko marko 11357184 19.1. 13:45 63240002.img -rw-r--r-- 1 marko marko 7699968 19.1. 13:45 63240003.img +63240001: 2768896,890880 to 2899968,1472512 +# : 59.414063,19.116211 to 62.226562,31.596680 +63240002: 2899968,890880 to 3020800,1472512 +# : 62.226562,19.116211 to 64.819336,31.596680 By the way, I tried to merge the '2 and '3 tiles a few weeks ago, but split them again because a routing test failed. Tile '1 is biggest and growing fastest, because most population and map features are located there. Best regards, Marko
Hi Marko OK the directory overflows for that file because there are more than 64k blocks. You can either reduce the size of the file or use the --block-size=1024 parameter to make the blocks bigger and so reduce the number. The bug is that it doesn't trigger the error message when the directory overflows as it normally does. It should give the message: "Too many blocks. Use a larger block size with an option such as --block-size=1024 or ..." It should be possible to make mkgmap adjust the block size automatically - it does for the gmapsupp.img for example, which almost always needs a block size greater than 512 if there is more than one .img in it. ..Steve
participants (2)
-
Marko Mäkelä -
Steve Ratcliffe