I don't have enough insight to the file format but this could well be the case. Could you explain in a few words, how it works?
The NOD section is like you describe it.
The point about the different levels being linked is in the NET section. Here is a a single road in NET:
| | | Road number 264, at offset 0015d2 00001609 | 0015d2 | 7d 08 00 | Label offset: 87d (^DA1 WATFORD WAY) 0000160c | 0015d5 | 89 08 00 | Label offset: 889 (WATFORD WAY (A1)) 0000160f | 0015d8 | 77 08 80 | Label offset: 877 (A1) 00001612 | 0015db | 56 | Flags 56 00001613 | 0015dc | 32 01 00 | Road len 612 meters 00001616 | 0015df | 01 | count 1 00001617 | 0015e0 | 01 | count 1 00001618 | 0015e1 | 01 | count 1 00001619 | 0015e2 | 01 | count 1 0000161a | 0015e3 | 81 | count 1 0000161b | 0015e4 | 10 | Level 0: line 16 0000161c | 0015e5 | 23 00 | in subdiv 35 0000161e | 0015e7 | 0b | Level 1: line 11 0000161f | 0015e8 | 0f 00 | in subdiv 15 00001621 | 0015ea | 09 | Level 2: line 9 00001622 | 0015eb | 05 00 | in subdiv 5 00001624 | 0015ed | 03 | Level 3: line 3 00001625 | 0015ee | 03 00 | in subdiv 3 00001627 | 0015f0 | 02 | Level 4: line 2 00001628 | 0015f1 | 02 00 | in subdiv 2 0000162a | 0015f3 | 00 | house number blocks? 0 0000162b | 0015f4 | ec | 0000162c | 0015f5 | 09 | zip/city index 9 0000162d | 0015f6 | 01 | flags for bytes following 1 0000162e | 0015f7 | 48 07 | nod pointer 0748
This says that the same road is line 16 in subdivision 35 at level 0, line 11 in subdivision 15 at level 1 and so on.
In this example there is only one line at each level. But there can be, say, one line at level 4, and five lines at level 0, all representing the same stretch of road.
Hmm, I just looked at a complete file and didn't find any example where there was more than one segment at level 0. Don't know if that is because it never happens in mkgmap or if it is because roads are never long enough to trigger this in the particular input file.
Thanks for explanation. Now I see some things much clearer. With this insight I think the current mergeline implementation has some structural problems. Merging the lines after the nets are created will lead to problems for sure. At the moment I must dicourage the use of the --mergelines option.
As felix has written too, the basic idea was to merge the lines as soon as possible after reading from osm. So it should not matter if the line was one line in osm, or multiple lines merged by mkgmap. But there was some problem with it which made it impossible. I cannot remember for the moment.
I will look into it. There is probably just no obvious place to do this in the code and we may need a bit of a re-organization.
After thinking a while, I remembered the problems. They are some logical problems. Consider a street with some different segements. One some segments there are lower speed limits, on other segements there is a different number of lines and so on. It is not possible (or at least not reasonable) to merge this segments before generating the routing data, because the routing data is affected by these properties. So I thought, ok lets merge at least the graphical representation. There is much more chance to merge lines, because only a few properties (Name and type of object) matters. And this would bring most effect, as it supports the dp filter. Now I see the problems rather clearly. If the segments cannot be merged in the NOD data, then they cannot be merged in the NET data too. Seems the whole concept of merging needs to be rethought. Regards, Johann