Hi Robert,
It's very barely tested: I created two small .mp-files with boundary node data, where some of the boundary nodes were actual junction nodes and some weren't. I loaded the combined gmapsupp.img on my GPS, and routing across tile boundaries worked partially; it seemed to work fine in the vicinity of non-junction boundary nodes. I didn't test this with MapSource.
A first thing to do to confirm the patch does what it should would be to run two such tiles through test.display.NodDisplay and see if the NOD3-entries are what you'd expect. There should be one per boundary node. (Furthermore, the corresponding entries in NOD1 should have a flag set.)
I have done what you suggested and, at first glance, the NodDisplay output looks reasonable. Here's a typical NOD1 node: | | | New node 00000329 | 0002ea | 1e | low 1e 0000032a | 0002eb | 4c | Flags 4c | | | : boundry-node 0000032b | 0002ec | 30 0b 11 | longitude 11.20605 | | | latitude 48.30191 0000032e | 0002ef | 79 | alt6 byte 79 | | | newdir 0, extra 38, destclass 1 | | | sign true 0000032f | 0002f0 | bd dd | last one | | | pointer to another node fddd | | | -> node c7 00000331 | 0002f2 | 10 | pointer to local net index 16 00000332 | 0002f3 | 94 02 | length 148 00000334 | 0002f5 | 65 | direction 142 degrees | | | ------ I know nothing about this encoding so this may be completely stupid but I notice that it says 'last one'. I'm guessing that this means it's the last node in the way but should that be asserted for a boundary node? Cheers, Mark