[mkgmap-dev] [Patch v1] Don't write useless data to NET file

Sat Oct 12 08:58:57 BST 2013

Hi Steve,
> 
> >@Steve: I assume that the Garmin maps contain also 
> >data for lower resolutions in NET, so maybe they also
> >have NOD data that points to this while we have not? 
> 
> I doubt that the data is useless, since that is how the maps are meant to be.  I do not know what it is for, but I would guess it would be only used on a GPS device and that it would have nothing directly to do with auto-routing, since it is NOD that controls that.

yes, I agree. 
> 
> It could be just used as an optimisation, rather than being essential. Or it may not be used on modern devices. Anyway lots of investigation needed before declaring it un-used.
That's why I posted the patch. I came across this issue when I tried to optimize the filters regarding roads.
If anybody notices a difference it will help me to understand how the device uses the information.

> 
> I've noticed that we only ever seem to have one road segment in one NET entry, whereas there can be more than one. (And I thought at one time there really was multiple segment combined.)
Yes, that's because all the splitting is (now) done before we create a MapRoad instance. My Garmin "worldwide autoroute" map seems to have
multiple segments in NET, some of them also on levels > 0. Unfortunately, the display tool fails on it, so I have to correct that first.
> 
> Having a single NET entry containing multiple road lines might help routing by reducing the number of entries in NOD
Yes. This would be a different kind of a merge road algo. The longer I look at the code the more I get the feeling
that MapRoad should be collecting MapLines. On the other hand, the Garmin map also has different NET entries for a 
motorway like the A1 in Germany, so it seems that there are also good reasons for splitting.

> 
> Of course if we are writing the wrong thing then that is kind of useless :-) and I would not be surprised if there were several bugs.
If I got that right, NET data is not optimized for sequential read access, means, it is probably only used 
with pointers from indexes or NOD. If that is true, we can omit all data that is not indexed or written to
NOD. As NET contains pointers to NOD, it is probably wrong to write NET data from merged roads containing 
pointers to the unmerged version of the road. I am still learning where we (or MapSource) calculate pointers 
to NET. 

Gerd

 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.mkgmap.org.uk/pipermail/mkgmap-dev/attachments/20131012/06473441/attachment-0001.html