[Patch v1] Don't write useless data to NET file
Hi, I think mkgmap writes too much data to the NET file, or some of it is probably wrong. Since r2586 we "use merge-lines for all lines in all resolutions, except for roads in res 24" In MapBuilder.LineAddFilter we have code that checks whether a line is a road, if yes, the MapLine is added to the corresponding RoadDef instance and later it is written to the NET file. We do this for all resolutions, no matter wheter the road was merged with other lines or not. I wondered why this did not cause trouble, as a RoadDef instance now may point to very different polylines at the different resolutions. I changed the code so that we only add the line to the RoadDef in resolution 24. See attached patch. reduce_net_v1.patch <http://gis.19327.n5.nabble.com/file/n5781077/reduce_net_v1.patch> I did not see any change in MapSource, routing etc. seems to work as before, but the img file size was reduced from ~140Mb to ~130MB. Compiled binary based on trunk version r2748 is here: http://files.mkgmap.org.uk/download/157/mkgmap.jar @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? Gerd -- View this message in context: http://gis.19327.n5.nabble.com/Patch-v1-Don-t-write-useless-data-to-NET-file... Sent from the Mkgmap Development mailing list archive at Nabble.com.
Hi Gerd,
I changed the code so that we only add the line to the RoadDef in resolution 24.
Could you make it level 0 instead resolution 24? I create maps with levels=0:23. Currently routing crashes in Mapsource but maybe it could be corrected? Another question: is it possible to create non-routable map with address search? If I create routable map, then I can strip NOD subfiles and get required result. I expected that I could get the same directly using options --net and --index, but this doesn't work. Sorry, in both cases I haven't tested latest code, these are my experiences form previous versions. -- Best regards, Andrzej
Hi Andrzej,
so that we only add the line to the RoadDef in resolution 24.
Could you make it level 0 instead resolution 24?
I create maps with levels=0:23. Currently routing crashes in Mapsource but maybe it could be corrected? yes, current code works only if level 0 is on resolution 24. I think this can be changed, we probably just have to change some "if (resolution==24)" to "if (resolution==getHighestRes())" or similar.
Another question: is it possible to create non-routable map with address search? If I create routable map, then I can strip NOD subfiles and get required result. I expected that I could get the same directly using options --net and --index, but this doesn't work.
Maybe this is related to other options. Please try using --tdbfile as well. Gerd
Hi,
Another question: is it possible to create non-routable map with address search? If I create routable map, then I can strip NOD subfiles and get required result. I expected that I could get the same directly using options --net and --index, but this doesn't work.
I don't know if that was possible in the past, but today and also with very old versions (tested r1060) --net without --route produces an empty NET section in the img file. I think it is like that since --route exists. Gerd
@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. 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. 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.) Having a single NET entry containing multiple road lines might help routing by reducing the number of entries in NOD 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. ..Steve
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
Hi Steve!
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.
I have heard gossips, that NET is used for functions like lock position on road and show next crossing street name. Maybe these functions need data on each layer. -- Best regards, Andrzej
Hi Steve, seems that my idea was already tried with r909 in 2009, and Robert Vollmert wasn't happy with it: http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2009q1/000776.html I still try to understand what he means... Gerd
From: steve@parabola.me.uk Date: Fri, 11 Oct 2013 23:21:59 +0100 To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] [Patch v1] Don't write useless data to NET file
@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.
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.
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.)
Having a single NET entry containing multiple road lines might help routing by reducing the number of entries in NOD
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.
..Steve
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi, maybe NET is responsible for positioning hint point in Mapsource? Try selection tool in Mapsource and point it to a road at different zooms. When on layer 0, Mapsource mark a point on road near the arrow end. But on higher layers marked point can be quite far away from arrow, see example in attached screen shot. -- Best regards, Andrzej
participants (4)
-
Andrzej Popowski -
Gerd Petermann -
GerdP
-
Steve Ratcliffe