logo separator

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

From Johann Gail johann.gail at gmx.de on Sun Nov 7 22:08:47 GMT 2010

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



More information about the mkgmap-dev mailing list