Currently the --merge-lines works in all resolutions. However in resolution 24 and 22 there is not much speed improvement on the GPS, but it's quite annoying that the information pop up on hoover shows in the wrong place. It would be great if one could specify the first resolution from which the --merge-lines is actually used. I think 21 or 20 down, would be best, but setting it via the commandline or "options" file would be better than hardcoding it.
On 31/10/10 07:33, Felix Hartmann wrote:
Currently the --merge-lines works in all resolutions. However in resolution 24 and 22 there is not much speed improvement on the GPS, but
It works at resolutions less than 24. So it would be expected that it makes no difference at resolution 24.
it's quite annoying that the information pop up on hoover shows in the wrong place. It would be great if one could specify the first resolution from which the --merge-lines is actually used. I think 21 or 20 down, would be best, but setting it via the commandline or "options" file
It looks to be easy to do that, but isn't it likely that something is wrong with it? Why are the labels in the wrong place? ..Steve
On 31.10.2010 23:44, Steve Ratcliffe wrote:
On 31/10/10 07:33, Felix Hartmann wrote:
Currently the --merge-lines works in all resolutions. However in resolution 24 and 22 there is not much speed improvement on the GPS, but It works at resolutions less than 24. So it would be expected that it makes no difference at resolution 24. It currently works at all resolutions. However at 24 and 22 I could not note any speed difference on GPS (Vista HCx, which has a rather slow processor, on Dakota or other "new" units I would expect the difference to be noticeable even at lower resolutions) it's quite annoying that the information pop up on hoover shows in the wrong place. It would be great if one could specify the first resolution from which the --merge-lines is actually used. I think 21 or 20 down, would be best, but setting it via the commandline or "options" file It looks to be easy to do that, but isn't it likely that something is wrong with it? Why are the labels in the wrong place? Labels and, and that is more important the tooltips show up at completly wrong places. And if you drag the map in Mapsource, you're not dragging from the point of departure, but the place where the tooltip showed up wrongly, so when you pan the map jumps really weird sometimes (you don't end up where you wanted to, but somewhere else).
I'm not sure how the code works currently, but ideally it should be working on every resolution separately. For example while at resolution 21-24 I add the name of bicycle, or mtb routes to the name of the street, I don't do this for 21-18 - hence more parts of the same road can be merged - and hence more speed increase. Also the tooltip problem is less apparent on 21 or 20 because the distance in meters it shows up wrong stays consistent - so it is much on screen fewer pixels. Also on the GPS the tooltip shows wrong, and here it's even worse, cause it might be outside of the display. Therefore (and as it's advantages only become apparent once you are in low resolutions) - I would like to have it working from 16-20 or 16-21 (would have to test this on the field), but definitely not in resolution 22 and 24.
..Steve _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi
It currently works at all resolutions. However at 24 and 22 I could not
Well all I can say is that the code is only called for resolutions less than 24: if (mergeLines && res < 24) { LineMergeFilter merger = new LineMergeFilter(); lines = merger.merge(lines); } The resolution 24 may be affected somehow by the other levels on the device somehow I suppose.
I'm not sure how the code works currently, but ideally it should be working on every resolution separately. For example while at resolution
Currently it does apply at every resolution separately, but I think that is likely the problem. It is also not done to the road definitions which can't be right. There is no advantage of working on each resolution separately with the way the code exists since it starts out as one single set of lines and as long as you take care to not join lines that are meant to be displayed at different levels, then there is nothing I think you can do per level that you can't do before calculating the subdivisions. I think that the place to do merging is before the subdivisions are created. I realise that one of the comments was that there is no suitable 'in between' place to do this, but I'd be happy if need be to introduce such a place. I also think that the lines must be merged before adding to the road network. ..Steve
On 01.11.2010 23:28, Steve Ratcliffe wrote:
Hi
It currently works at all resolutions. However at 24 and 22 I could not Well all I can say is that the code is only called for resolutions less than 24:
if (mergeLines&& res< 24) { LineMergeFilter merger = new LineMergeFilter(); lines = merger.merge(lines); }
The resolution 24 may be affected somehow by the other levels on the device somehow I suppose. Ups no, sorry for the trouble. There are no probs on resolution=24. So an intermediary fix would be to take out 22 and 23 because 22 is still for many outdoor sports the most used resolution on the GPS and not used for overview (where am I? where is place X that I want to got to?) and hence no speed increase in map drawing is really needed (anyhow it is very small - it gets larger the further one zooms out). I use 21 usually not anymore while following a trail on bicycle or hiking - hence here the problems are not so severe.
Which file is this in? If so would changing this to if (mergeLines&& res< 22) { LineMergeFilter merger = new LineMergeFilter(); lines = merger.merge(lines); } work out for me? Or do I run into problems on further lines? (I do think this should be changed on the trunk too - I got about 15 mails/comments about this bug from users of my map after I put --merge-lines into my build process during 2 days....)
I'm not sure how the code works currently, but ideally it should be working on every resolution separately. For example while at resolution Currently it does apply at every resolution separately, but I think that is likely the problem. It is also not done to the road definitions which can't be right. What do you mean by this? In my eyes any road type (e.g. 0x01) could be merged as long as there is no change in name (because routing is only at resolution=24 - so no need to look whether road_class or road_speed are the same, that would only apply for resolution=24 (or resolution=23 if you produce maps without 24 - but mkgmap is severly broken in that regard anyhow. You currently cannot get a map to work that has resolution=23 as routing and most detailed resolution without big problems (at least 6 month ago when I tried this)). There is no advantage of working on each resolution separately with the way the code exists since it starts out as one single set of lines and as long as you take care to not join lines that are meant to be displayed at different levels, then there is nothing I think you can do per level that you can't do before calculating the subdivisions.
I think that the place to do merging is before the subdivisions are created. I realise that one of the comments was that there is no suitable 'in between' place to do this, but I'd be happy if need be to introduce such a place.
I also think that the lines must be merged before adding to the road network. Yes that would be best to do. But may be difficult - because you would have to parse the style-file first to find out whether or not the parts can be merged or not. ..Steve _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Which file is this in? If so would changing this to
if (mergeLines&& res< 22) { LineMergeFilter merger = new LineMergeFilter(); lines = merger.merge(lines); }
work out for me? Or do I run into problems on further lines? (I do think
Yes that should be all thats needed. I can apply that to trunk too.
Currently it does apply at every resolution separately, but I think that is likely the problem. It is also not done to the road definitions which can't be right. What do you mean by this? In my eyes any road type (e.g. 0x01) could be
Oh I meant internally, there is a class that keeps track of all the roads for routing, separately from the lines that get drawn. So a road is held within mkgmap in two places but only one is merged. Roads at different levels are linked together via NET and well I'd have to look at it again to be sure, but it feels like that would cause a problem to me.
the same, that would only apply for resolution=24 (or resolution=23 if you produce maps without 24 - but mkgmap is severly broken in that regard anyhow. You currently cannot get a map to work that has resolution=23 as routing and most detailed resolution without big problems (at least 6 month ago when I tried this)).
It would be nice to get routing working at r=23, it may not be that broken, I remember seeing a few pieces of code that assume 24 it may work if they were fixed. ..Steve
On 02.11.2010 00:28, Steve Ratcliffe wrote:
Which file is this in? If so would changing this to
if (mergeLines&& res< 22) { LineMergeFilter merger = new LineMergeFilter(); lines = merger.merge(lines); }
work out for me? Or do I run into problems on further lines? (I do think Yes that should be all thats needed.
I can apply that to trunk too.
Currently it does apply at every resolution separately, but I think that is likely the problem. It is also not done to the road definitions which can't be right. What do you mean by this? In my eyes any road type (e.g. 0x01) could be Oh I meant internally, there is a class that keeps track of all the roads for routing, separately from the lines that get drawn. So a road is held within mkgmap in two places but only one is merged.
Roads at different levels are linked together via NET and well I'd have to look at it again to be sure, but it feels like that would cause a problem to me.
the same, that would only apply for resolution=24 (or resolution=23 if you produce maps without 24 - but mkgmap is severly broken in that regard anyhow. You currently cannot get a map to work that has resolution=23 as routing and most detailed resolution without big problems (at least 6 month ago when I tried this)). It would be nice to get routing working at r=23, it may not be that broken, I remember seeing a few pieces of code that assume 24 it may work if they were fixed.
Oh well, would be quite nice. I think that maybe long distance routing could be improved a lot, as all Garmin maps that are working well for autorouting, actually start with resolution 23. then one could move all POI to a seperate layer, so that most only appear at resolution 24 cause 23 would mean that one has to kick many more out ...
..Steve _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hello Steve, I'm the origin writer of the mergeline code. It was a try to improve the effectiveness of the dp filter. When a nearly straight way consists of severeal short pieces, dp filter could not do much. If the segments are combined beforehand, dp filter could work much better and combine it in best case to a single straight line. The correct place for calling it would be before generating the subdivisions and the routing data. And it should be called only one time, not for each resolution. But at the time of writing the filter network does not give the possibility for a hook 'in between'. Or at least I have not found it. 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. Steve Ratcliffe schrieb:
Which file is this in? If so would changing this to
if (mergeLines&& res< 22) { LineMergeFilter merger = new LineMergeFilter(); lines = merger.merge(lines); }
work out for me? Or do I run into problems on further lines? (I do think
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 of ways gets merged, and so the small offset of 1km will be e.g. 10km. So at res 21 it is visible again. Also now I remember of the --mergelines option to be breaking the routing because of the differences of the draw and the routing data. Does routing on the generated maps work nowadays (except from the wrong destination point)?
Currently it does apply at every resolution separately, but I think that is likely the problem. It is also not done to the road definitions which can't be right.
What do you mean by this? In my eyes any road type (e.g. 0x01) could be
Oh I meant internally, there is a class that keeps track of all the roads for routing, separately from the lines that get drawn. So a road is held within mkgmap in two places but only one is merged.
Roads at different levels are linked together via NET and well I'd have to look at it again to be sure, but it feels like that would cause a problem to me.
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? There is the routing data (NOD) and the draw data (NET). To my understanding, NOD data exists only one time. It contains the data like of res 24 but resolution does not mean anything here. Each segment in this data points to a line in the NET data. But how works this with lower resolutions? Are there pointers for each resolution? 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. Regards, Johann
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
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
Currently the --merge-lines works in all resolutions. However in resolution 24 and 22 there is not much speed improvement on the GPS, but it's quite annoying that the information pop up on hoover shows in the wrong place. I can vaguely remember seeing a similar effect a year ago. I didn't search deeper, but my assumption was that this is some side effect of the dp filter. It looks to me that the pop up (and sometimes the pink routing line) was drawn at an invisible straightened line instead of being aligned with the visible objects.
Could you describe more exactly, how this pop up is missaligned? Is it on the line, but on the wrong position or is it completly off the line? Johann
On 01.11.2010 09:27, Johann Gail wrote:
Currently the --merge-lines works in all resolutions. However in resolution 24 and 22 there is not much speed improvement on the GPS, but it's quite annoying that the information pop up on hoover shows in the wrong place. I can vaguely remember seeing a similar effect a year ago. I didn't search deeper, but my assumption was that this is some side effect of the dp filter. It looks to me that the pop up (and sometimes the pink routing line) was drawn at an invisible straightened line instead of being aligned with the visible objects.
Could you describe more exactly, how this pop up is missaligned? Is it on the line, but on the wrong position or is it completly off the line?
It is on the line, but sometimes up to 1km wrong position - though mostly 100-200m away. It this is a bug that can be fixed - than disregard my comment to drop the support at resolution 24, but I remember Mark Button (hey, I miss you and your great coding BTW), writing that it is inherent to the function itself - though I don't understand why - to me it should not matter whether a road was a single part in OSM or two parts and merged (but on single part roads this bug is not showing up, so likely it can be fixed...).
Johann
Here is a screenshot from Mapsource, where you can see the problem (pop up is around 900m off - that's out of the screen on the GPS in most zoom levels): (the pop up should be right besides the hand symbol) On 01.11.2010 09:27, Johann Gail wrote:
Currently the --merge-lines works in all resolutions. However in resolution 24 and 22 there is not much speed improvement on the GPS, but it's quite annoying that the information pop up on hoover shows in the wrong place. I can vaguely remember seeing a similar effect a year ago. I didn't search deeper, but my assumption was that this is some side effect of the dp filter. It looks to me that the pop up (and sometimes the pink routing line) was drawn at an invisible straightened line instead of being aligned with the visible objects.
Could you describe more exactly, how this pop up is missaligned? Is it on the line, but on the wrong position or is it completly off the line?
Johann
One more problem, you cannot route onto those broken roads, as the routing will go to the place the popup is at. That means any merged-line, cannot be choosen as a destination for autorouting (or said, you cannot decide where on the road you'll end up). See following screenshot (same problem on GPS): Instead of being routed to where I clicked (see where the mouse is) - I get routed onto the other side of the trail!
One more problem, you cannot route onto those broken roads, as the routing will go to the place the popup is at. That means any merged-line, cannot be choosen as a destination for autorouting (or said, you cannot decide where on the road you'll end up).
See following screenshot (same problem on GPS): Instead of being routed to where I clicked (see where the mouse is) - I get routed onto the other side of the trail!
Thank you for the screenshots. It shows another problem with the dp filter too. If you look closely, you will see a small discrepancy between the drawn track and the pink routing line at the sharp corner. This has the same background: The routing data does not match the draw line data. Seems we need to think about the filter structure in general. These filters have to be applied both before the generation of routing data. Regards, Johann
Just for reference. I found the old thread: http://www.mail-archive.com/mkgmap-dev@lists.mkgmap.org.uk/msg03680.html So if there is no way to correct it right (merge-lines before routing layer for resolution 24) - then I would support dropping merge-lines for resolution 24 and 22 by default (the error at 20 or 21 is much less apparent).
Just for reference. I found the old thread: http://www.mail-archive.com/mkgmap-dev@lists.mkgmap.org.uk/msg03680.html
Thanks for searching the old thread. It is true, now I can remember too. The problem was (and I think is) that the routing tables are generated before the merging. So the displayed lines does not match the rounting and pop up data. The solution would be to do the merging before creating the routing tables. I would expect it to have some small positive effect to the routing data too. But with the given structure of the code it is not easy to implement.
So if there is no way to correct it right (merge-lines before routing layer for resolution 24) - then I would support dropping merge-lines for resolution 24 and 22 by default (the error at 20 or 21 is much less apparent).
I'm sorry, but I will not have time the next weeks to investigate deeper. As I have read from Steves comment, the merge line code should not be called at resolution 24. I would have to check again, but I think this was the solution for the old thread. Not merging the lines at resolution 24 does not lead to discrepancies to the routing data. So it should be checked, why this code is executed at resolution 24. Johann
participants (3)
-
Felix Hartmann -
Johann Gail -
Steve Ratcliffe