[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
- Previous message: [mkgmap-dev] RFE --merge-lines only from resolution X
- Next message: [mkgmap-dev] RFE --merge-lines only from resolution X
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the mkgmap-dev mailing list