Hi Steve, the NetCheck displays some messages like this: ERROR: node-count=6, nblocks=0 [VIA VITTORIO VENETO] 1afd I don't understand why the node-count value is compared with def.nblocks The write routine in mkgmap doesn't write the number of nodes to the place where display tool reads the def.nblocks value. Am I missing something? Gerd -- View this message in context: http://gis.19327.n5.nabble.com/question-reg-display-tool-tp5759106.html Sent from the Mkgmap Development mailing list archive at Nabble.com.
Hi Gerd, On 30/04/13 09:07, GerdP wrote:
I don't understand why the node-count value is compared with def.nblocks The write routine in mkgmap doesn't write the number of nodes to the place where display tool reads the def.nblocks value.
I was developing a patch to fill in that value. Although it seems to work without it, I thought it might be the cause of the routing problem with house numbers active. But anyway there is no harm in having it filled in. The current patch is attached. There is still some debugging in which I will tidy up later. ..Steve
Hi Steve, okay, sounds reasonable. For now I'll disable the check in display tool. By the way: NetCheck evalualtes the counter with 10 bits , but your patch only writes the lower 8 bits. Is this because we never have more than 255 points in one way? If yes: why is the img format using 10 bits for the counter? I assume it is for a roadDef that combines several parts? Gerd Steve Ratcliffe wrote
Hi Gerd,
On 30/04/13 09:07, GerdP wrote:
I don't understand why the node-count value is compared with def.nblocks The write routine in mkgmap doesn't write the number of nodes to the place where display tool reads the def.nblocks value.
I was developing a patch to fill in that value.
Although it seems to work without it, I thought it might be the cause of the routing problem with house numbers active. But anyway there is no harm in having it filled in.
The current patch is attached. There is still some debugging in which I will tidy up later.
..Steve
_______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Write_block_count_for_housenumbers.patch (17K) <http://gis.19327.n5.nabble.com/attachment/5759155/0/Write_block_count_for_ho...;
-- View this message in context: http://gis.19327.n5.nabble.com/question-reg-display-tool-tp5759106p5759235.h... Sent from the Mkgmap Development mailing list archive at Nabble.com.
okay, sounds reasonable. For now I'll disable the check in display tool. By the way: NetCheck evalualtes the counter with 10 bits , but your patch only writes the lower 8 bits. Is this because we never have more than 255 points in one way?
Right, thanks, it isn't writing the top bits as it should. Although as you've discovered we don't have more than 255 points in a way and there never seems to be more than one road segment in a roaddef, so at the moment it isn't possible for us to overflow 8 bits. But you are right and I will fix that before commiting.
If yes: why is the img format using 10 bits for the counter? I assume it is for a roadDef that combines several parts?
Yes I believe that is the case. ..Steve
Steve Ratcliffe wrote
Although as you've discovered we don't have more than 255 points in a way and there never seems to be more than one road segment in a roaddef, so at the moment it isn't possible for us to overflow 8 bits.
I am trying to change the program flow (moving calcs from StyledConverter to MapBuilder or lower routines) so that we can use mergel-lines with roads. We'll then have more than one segment in a roaddef. Up to now the result is completely broken routing, but I probably did not find all neccessary changes. Gerd -- View this message in context: http://gis.19327.n5.nabble.com/question-reg-display-tool-tp5759106p5759308.h... Sent from the Mkgmap Development mailing list archive at Nabble.com.
participants (2)
-
GerdP -
Steve Ratcliffe