Commit: r1054: When subdivision fails to reduce number of nodes, report bbox and croak.
Version 1054 was commited by markb on 2009-06-02 10:04:38 +0100 (Tue, 02 Jun 2009) When subdivision fails to reduce number of nodes, report bbox and croak. At least now you will get a bbox reported so you can find the bad data. Not implemented as an assertion because they may not be enabled.
On Tue, Jun 2, 2009 at 11:04 AM, svn commit <svn@mkgmap.org.uk> wrote:
Version 1054 was commited by markb on 2009-06-02 10:04:38 +0100 (Tue, 02 Jun 2009)
When subdivision fails to reduce number of nodes, report bbox and croak.
You know, I'm not too crazy about the "croak" part. For example, yesterday I attempted to compile a map of a large portion of Europe from Geofabrik.de, which provides daily extracts. The entire procedure took many hours (osmosis -> split -> mkgmap) on my antiquated (2 years old) hardware. Sometime in the middle of the night, I ended up with the "croak" and a polite apology that the map could not be compiled due to an invalid bbox somewhere. Now to correct this, I would have to figure out where the invalid data came from, try to correct it, upload it, and wait another day until the Geofabrik extract is available, and then start again. This may be a considerable incentive to correct the bad data ;-), but it is inconvenient, to say the least, when attempting to compile large areas. :-( Er... would it be possible to warn and continue with the compilation, knowing that parts of the map would be corrupt? (a "--force" option, or something?) Cheers.
For me this is the same. However why did this problem not appear until now? a) has something in mkgmap changed or b) is there some tool out that destructs osm data by mistake? Clinton Gladstone wrote:
On Tue, Jun 2, 2009 at 11:04 AM, svn commit <svn@mkgmap.org.uk> wrote:
Version 1054 was commited by markb on 2009-06-02 10:04:38 +0100 (Tue, 02 Jun 2009)
When subdivision fails to reduce number of nodes, report bbox and croak.
You know, I'm not too crazy about the "croak" part.
For example, yesterday I attempted to compile a map of a large portion of Europe from Geofabrik.de, which provides daily extracts. The entire procedure took many hours (osmosis -> split -> mkgmap) on my antiquated (2 years old) hardware. Sometime in the middle of the night, I ended up with the "croak" and a polite apology that the map could not be compiled due to an invalid bbox somewhere.
Now to correct this, I would have to figure out where the invalid data came from, try to correct it, upload it, and wait another day until the Geofabrik extract is available, and then start again.
This may be a considerable incentive to correct the bad data ;-), but it is inconvenient, to say the least, when attempting to compile large areas. :-(
Er... would it be possible to warn and continue with the compilation, knowing that parts of the map would be corrupt? (a "--force" option, or something?)
Cheers. _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Felix,
a) has something in mkgmap changed
No, it has always (well at least as far as I have been involved with it!) been capable of failing in this way.
b) is there some tool out that destructs osm data by mistake?
Or is there some dumb mapper who generated the same ways 50 times? Cheers, Mark
b) is there some tool out that destructs osm data by mistake?
Or is there some dumb mapper who generated the same ways 50 times?
Just a thoght: May it have to do something with the new v0.6 interface? May this ways be old revisions or somthing similar?
On Wed, Jun 03, 2009 at 03:12:59PM +0100, Mark Burton wrote:
Hi Felix,
a) has something in mkgmap changed
No, it has always (well at least as far as I have been involved with it!) been capable of failing in this way.
b) is there some tool out that destructs osm data by mistake?
Or is there some dumb mapper who generated the same ways 50 times?
Tool or fool, isn't it the same thing? :-) Joking aside, finland.osm.bz2 compiled just fine with mkgmap -r1057 --max-jobs. While it was doing the job, I was editing a ride, removing orphaned points and merging a duplicated point. It's great that mkgmap can work around some forms of brokenness. Marko
Hi Clinton,
You know, I'm not too crazy about the "croak" part.
For example, yesterday I attempted to compile a map of a large portion of Europe from Geofabrik.de, which provides daily extracts. The entire procedure took many hours (osmosis -> split -> mkgmap) on my antiquated (2 years old) hardware. Sometime in the middle of the night, I ended up with the "croak" and a polite apology that the map could not be compiled due to an invalid bbox somewhere.
Now to correct this, I would have to figure out where the invalid data came from, try to correct it, upload it, and wait another day until the Geofabrik extract is available, and then start again.
This may be a considerable incentive to correct the bad data ;-), but it is inconvenient, to say the least, when attempting to compile large areas. :-(
Er... would it be possible to warn and continue with the compilation, knowing that parts of the map would be corrupt? (a "--force" option, or something?)
It's a tricky situation because by the time the problem is detected lots of half built data structures are around some of which will refer to the nodes/ways that are going to have to be thrown away to be able to carry on without croaking. I will have a go a trying to find a means of continuing in this situation but it's likely that the resulting map will be broken as far as routing is concerned. Let's see what can be done. Cheers, Mark
participants (6)
-
Clinton Gladstone -
Felix Hartmann -
Johann Gail -
Mark Burton -
Marko Mäkelä -
svn commit