[PATCH v1] increase Table B size
Support larger Table B sizes. Until now, we have limited Table B to less than 0x40 entries but by using an extra byte to hold the Table B index in RouteArc objects, the number of entries can be increased up to a new limit of 0x100. Just discovered that Table B can actually be larger than we have been using. Table B overflow is one of the criteria for dividing a route centre so by allowing them to be larger, it should reduce the number of route centre splits. Having said that, on the GB map data, only a few Table B's grew larger than the previous limit so I think the benefit is probably marginal. Still, for complex city regions it could make a difference. I have verified that for the GB map, those roads that cause a Table B to be larger than the previous limit are routable as normal. Anyway, please test if you can and as long as it doesn't introduce any problems it's worth incorporating this. Mark
On Nov 23, 2009, at 16:13, Mark Burton wrote:
Support larger Table B sizes.
I tested the patch on a map of Germany. When I did, I received the following error: SEVERE (BlockManager): overflowed directory with max block 65534, current=65535 Too many blocks. Use a larger block size with an option such as --block-size=16384 or --block-size=32768 This is new. I have not yet tested to see if the map is broken or not though. Cheers.
On Mon, 23 Nov 2009 23:27:38 +0100 Clinton Gladstone <clinton.gladstone@googlemail.com> wrote:
On Nov 23, 2009, at 16:13, Mark Burton wrote:
Support larger Table B sizes.
I tested the patch on a map of Germany. When I did, I received the following error:
SEVERE (BlockManager): overflowed directory with max block 65534, current=65535 Too many blocks. Use a larger block size with an option such as --block-size=16384 or --block-size=32768
This is new. I have not yet tested to see if the map is broken or not though.
That's interesting, thanks for the report. I don't understand what it means though so it's probably not a good idea to commit that patch quite yet. Cheers, Mark
On Nov 23, 2009, at 23:36, Mark Burton wrote:
On Mon, 23 Nov 2009 23:27:38 +0100 Clinton Gladstone <clinton.gladstone@googlemail.com> wrote:
On Nov 23, 2009, at 16:13, Mark Burton wrote:
Support larger Table B sizes.
I tested the patch on a map of Germany. When I did, I received the following error:
SEVERE (BlockManager): overflowed directory with max block 65534, current=65535 Too many blocks. Use a larger block size with an option such as --block-size=16384 or --block-size=32768
This is new. I have not yet tested to see if the map is broken or not though.
That's interesting, thanks for the report. I don't understand what it means though so it's probably not a good idea to commit that patch quite yet.
Strangely, with the same map, but after updating to r1404, the problem has disappeared. Perhaps the problem was caused by sunspots or something? Cheers.
Hi Clinton,
Strangely, with the same map, but after updating to r1404, the problem has disappeared.
Sorry, can you confirm that was with the Table B size increase patch applied to the latest SVN?
Perhaps the problem was caused by sunspots or something?
Weirdness abounds (must be the time of year). Cheers, Mark
On Nov 24, 2009, at 23:18, Mark Burton wrote:
Strangely, with the same map, but after updating to r1404, the problem has disappeared.
Sorry, can you confirm that was with the Table B size increase patch applied to the latest SVN?
Yes, I just checked again. The patch is applied. The error seems to have inexplicably disappeared. Cheers.
Yes, I just checked again. The patch is applied. The error seems to have inexplicably disappeared.
Hmm, well even if it comes back you can always do what it's telling you and specify a value for block-size (or whatever it was). As the maps get bigger that's probably going to be needed sometime anyway. Cheers
On Nov 25, 2009, at 23:49, Mark Burton wrote:
Yes, I just checked again. The patch is applied. The error seems to have inexplicably disappeared.
Hmm, well even if it comes back you can always do what it's telling you and specify a value for block-size (or whatever it was). As the maps get bigger that's probably going to be needed sometime anyway.
That was the first thing I tried. I then got an array out of bounds exception. Since the first error went away anyway, I did not pursue this further. I am not sure if the block size needs to be a multiple of something or other. I simply chose 90000 because that seemed like a nice number. mkgmap didn't like it though. Cheers
That was the first thing I tried. I then got an array out of bounds exception. Since the first error went away anyway, I did not pursue this further. I am not sure if the block size needs to be a multiple of something or other. I simply chose 90000 because that seemed like a nice number. mkgmap didn't like it though.
I think it has to be 2^N
participants (2)
-
Clinton Gladstone -
Mark Burton