[mkgmap-dev] RFE --merge-lines only from resolution X

Tue Nov 2 21:58:35 GMT 2010

Hi Johann

> I'm the origin writer of the mergeline code. It was a try to improve the

> I will be very happy if you can set the call of the filter at the
> correct place. Feel free to do it, I don't have the time nor a running
> IDE at the moment.

OK If I can see a good way to do it, I will.

>> Yes that should be all thats needed.
>>
>> I can apply that to trunk too.
>>
> I don't think this is a good idea. It seems to minimize the problems at
> first glance, but I'm sure you will find other situations, where a lot

Sure, I didn't mean that it was a good long term solution.

> 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.

> 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.

..Steve