pink line doesn't draw correctly
Hello, I have just discovered a new failure of drawing of the pinky line. I have compiled s small section of a map with mkgmap-nod (latest R881) to an img file. Routing works correctly, the text messages describes the correct way. But the pink line makes an jump to the end of the street. The streets contains only 5 and 7 nodes, so they shouldn't be to long. I've attached a screenshot of my etrex. The route should start at the bottom middle, go upwards, turn right, turn left, go on top of the screen. Instead it makes an jump to the end of the horizontal street. I've merged in R877 from the trunk, but there was no difference. I've tried to move around different nodes of the horizontal street a little to see the effect. There was no change.
Hi Johann,
I have just discovered a new failure of drawing of the pinky line. I have compiled s small section of a map with mkgmap-nod (latest R881) to an img file. Routing works correctly, the text messages describes the correct way. But the pink line makes an jump to the end of the street. The streets contains only 5 and 7 nodes, so they shouldn't be to long.
I've attached a screenshot of my etrex. The route should start at the bottom middle, go upwards, turn right, turn left, go on top of the screen. Instead it makes an jump to the end of the horizontal street.
I've merged in R877 from the trunk, but there was no difference. I've tried to move around different nodes of the horizontal street a little to see the effect. There was no change.
Does this also happen if you go via a mp file? BTW - how do you get your screenshot image? It's not the actual etrex screen is it? It looks more like a computer graphic. Cheers, Mark
BTW - how do you get your screenshot image? It's not the actual etrex screen is it? It looks more like a computer graphic.
This is an exact screenshot taken from my etrex Venture Cx. I have created it with QLandkarte (a linux replacement for mapsource) on my ubuntu system. What does there look not like an etrex graphic in your opinion?
This is an exact screenshot taken from my etrex Venture Cx. I have created it with QLandkarte (a linux replacement for mapsource) on my ubuntu system. What does there look not like an etrex graphic in your opinion?
It looks great but I just don't see how you can get a screenshot of the etrex without using a camera! I think, perhaps, that you are showing a reconstructed screenshot (a very good one) rather than a real screenshot. It's no big deal, I was just curious! Cheers, Mark
It looks great but I just don't see how you can get a screenshot of the etrex without using a camera! I think, perhaps, that you are showing a reconstructed
You can download the screenshot directly from the unit using the xImage program from Garmin, or QLandkarte can do the same thing. That is how the screenshots on the mkgmap wiki page were created. ..Steve
Does this also happen if you go via a mp file?
I've tried now the osm2mp way. There the pink line is correctly. Before trying osm2mp I've played with different positions of the nodes, move single nodes far from the street, move the street to the opposite direction (without crossing other streets), at last shortened the street node by node. Whatever I have done, there was no change. The pink line jumps to the end of the street. Are the streets in mkgmap internally merged or simplified or something similar? The streets are both residentials with no name, and have no further tags.
On Feb 14, 2009, at 14:43, Mark Burton wrote:
I've tried now the osm2mp way. There the pink line is correctly.
OK - is it possible for you to send me a region of your osm file (or the whole thing if it is not huge) so that I can check this out, please?
I'd like this, too -- to the list if it's small? Cheers Robert
If you reverse the direction of aa, the pink line appears to behave correctly. Something's not right here because there shouldn't be a node at the end of aa for the gps to route to anyway because it's a dead end. I shall investigate. Cheers, Mark
On Feb 14, 2009, at 15:25, Mark Burton wrote:
If you reverse the direction of aa, the pink line appears to behave correctly.
Something's not right here because there shouldn't be a node at the end of aa for the gps to route to anyway because it's a dead end. I shall investigate.
But you might want to route to the end of the road? Is the difference that osm2mp puts a node at the end while mkgmap-osm doesn't? In that case it'd still be nice to fix the bug without adding a node there. The issue is most likely with the extra bits in the polyline (TRE/RGN, LinePreparer) or the bits in NOD2 (RoadDef.writeNod2) which are both not fully understood. Cheers Robert
But you might want to route to the end of the road?
Yes, indeed. Further investigation shows that (with the way in it's orginal direction) you can route out of bb into aa in either direction and it will be OK. So it appears that you don't actually need a node at the end of a dead-end way to be able to route towards the end. As soon as you try and route out of aa (either to the N or S) you get the pink line going to the W end of aa. Cheers, Mark
Further investigation shows that (with the way in it's orginal direction) you can route out of bb into aa in either direction and it will be OK.
So it appears that you don't actually need a node at the end of a dead-end way to be able to route towards the end.
As soon as you try and route out of aa (either to the N or S) you get the pink line going to the W end of aa.
Just out of curiousity: Can you set the startpoint for routing on the etrex unit, or do you test it another way?
Can you give me an hint how to specify the current position? I cant find any menu to enter it or move to.
Sure, on my etrex vista, it's on the Satellite page menu "New Location". You then get the chance to specify your location on the map. Seems to involve lots of zooming but you get there in the end.
Further investigation shows that (with the way in it's orginal direction) you can route out of bb into aa in either direction and it will be OK.
So it appears that you don't actually need a node at the end of a dead-end way to be able to route towards the end.
As soon as you try and route out of aa (either to the N or S) you get the pink line going to the W end of aa.
I can confirm your results. More refined investigations: If routing starts on the east half of aa (between two nodes) everything is ok with every destination. If routing starts in the wast half of aa (with the missing end node) and destination is N or S then the purple line fills the whole segment. (Not starting from current position and going in the wrong direction, but the whole segment!). I agree, that there in theory should not be needed a node, as there is no junction between two streets. Routing works fine without the final node, but the drawing algorithm seems to need it. Latest news: I've just discovered, that the error has something to do with the zoom level! If I zoom out to 120m then the pink line draws correct.
Also if I zoom in so far that the connection between aa and bb is not visible on the screen, then the line drawing is correct.
Latest news: I've just discovered, that the error has something to do with the zoom level! If I zoom out to 120m then the pink line draws correct.
Also if I zoom in so far that the connection between aa and bb is not visible on the screen, then the line drawing is correct.
The theory is that at high zoom level, the route is drawn using the highest detail data from the polylines in TRE/RGN, which is linked to the routing graph via "extra bits" and NET. At low zoom levels, the route is drawn using just the data in NET/NOD ("level 1" in GDF, see http://libgarmin.wiki.sourceforge.net/ Contribute). Cheers Robert
Latest news: I've just discovered, that the error has something to do with the zoom level! If I zoom out to 120m then the pink line draws correct.
Also if I zoom in so far that the connection between aa and bb is not visible on the screen, then the line drawing is correct.
The theory is that at high zoom level, the route is drawn using the highest detail data from the polylines in TRE/RGN, which is linked to the routing graph via "extra bits" and NET.
At low zoom levels, the route is drawn using just the data in NET/NOD ("level 1" in GDF, see http://libgarmin.wiki.sourceforge.net/Contribute).
It seems, the error occurs only in very rare conditions: + Node in osm O Node in Routing graph The pink line should go through 6,2,1,7 |8 5 4 3 2 1 | dead end---+---+---O---+---O | | |6 |7 | O The error occurs only if segment 2 is to be drawn. The error occurs not if... ... if I zoom out enough, that segment 2 is only ~4 pixels long ... if I zoom and move the screen, so that segment 2 is off the screen ... if I generate a new map with an additional routing node between 2 and 1 ... if there is a end node at the dead end (from mark) ... if the direction of the way is inverted (from mark) ... if routing starts or ends in segment 1 or 2 As far as I understand the situation, the drawing algortihm has problems to find the correct segments to draw pink. If it has to draw all segments between two routing nodes (e.g. 1 and 2) then it will draw also 3,4,5. Seems like some search function didn't stop when it should. Maybe the node between 2 and 3 should have some special flag set. I will stop further investigation for now and will try the newest commits.
If you reverse the direction of aa, the pink line appears to behave correctly.
Good point, I haven't tried this.
Something's not right here because there shouldn't be a node at the end of aa for the gps to route to anyway because it's a dead end. I shall investigate.
At the moment I dont understand the meaning of your sentence. In my opinion there SHOULD be a node to be able to routing to, even in an dead end. But I dont know the internas of the routing far enough. While writing I belive I understand: It has to do with the bidirectional routing algorithm of the garmin device. From this dead end routing always starts. Anyway, the routing seems to be correct in my case, as the commands in the text list are correct. They say coorectly 'turn right, turn left'. Only the visual representation of the pink line gets displayed wrong.
If you reverse the direction of aa, the pink line appears to behave correctly.
Good point, I haven't tried this.
Something's not right here because there shouldn't be a node at the end of aa for the gps to route to anyway because it's a dead end. I shall investigate.
At the moment I dont understand the meaning of your sentence. In my opinion there SHOULD be a node to be able to routing to, even in an dead end. But I dont know the internas of the routing far enough.
No, I think that the nodes are how the routing jumps between ways, not how an individual way is traversed.
While writing I belive I understand: It has to do with the bidirectional routing algorithm of the garmin device. From this dead end routing always starts.
Anyway, the routing seems to be correct in my case, as the commands in the text list are correct. They say coorectly 'turn right, turn left'. Only the visual representation of the pink line gets displayed wrong.
Yes, I think it's perhaps more of a graphics bug in that it's choosing the wrong direction to draw the pink line? More thinking required... Mark
No, I think that the nodes are how the routing jumps between ways, not how an individual way is traversed.
I admit.
Yes, I think it's perhaps more of a graphics bug in that it's choosing the wrong direction to draw the pink line?
I would not say wrong direction but wrong node. Maybe there is some wrong ordering of the nodes in the way? I've looked into the mp file. There are for road aa three nodes, start, crossing, end. For road bb there are two nodes at start and end. So in the mp file there IS an node for the dead end. Maybe it gets removed in a following step.
Hello, During tests I found that there seems to be a routing problem if the destination is located at a oneway which contains multiple nodes. In the attachment you find a picture from the device (Edge705). The destination is shown as "003". It is located at a oneway named "Bahnzeile". I inserted an ugly black arrow, which should illustrate the direction of this oneway. The device somehow recognizes that the destination road is a oneway, because it does not instruct to turn right at the first crossing with the oneway. But It routes opposite to the oneway on the next crossing of that oneway. The green line shows the correct route. I generated the map with r896 and r869 using osm input. Both versions have the same problem. The OSM input looks OK. thanks Stefan
On Feb 16, 2009, at 21:10, Stefan Wenk wrote:
During tests I found that there seems to be a routing problem if the destination is located at a oneway which contains multiple nodes. In the attachment you find a picture from the device (Edge705). The destination is shown as "003". It is located at a oneway named "Bahnzeile". I inserted an ugly black arrow, which should illustrate the direction of this oneway. The device somehow recognizes that the destination road is a oneway, because it does not instruct to turn right at the first crossing with the oneway. But It routes opposite to the oneway on the next crossing of that oneway. The green line shows the correct route. I generated the map with r896 and r869 using osm input. Both versions have the same problem. The OSM input looks OK.
Thanks for the report. The oneway street is just one way in the .osm, right? Could you try going via .mp? It's unlikely to make a difference, but that way we could narrow it down somewhat. Or, could you send the output of "java test.display.NNDisplay" (from display svn)? Cheers Robert
On Wed, Feb 18, 2009 at 12:41 PM, Robert Vollmert <rvollmert-lists@gmx.net> wrote:
Thanks for the report. The oneway street is just one way in the .osm, right?
Could you try going via .mp? It's unlikely to make a difference, but that way we could narrow it down somewhat.
I just happened to notice this exact same error last night while driving home. I had an .mp version of the same map handy, and did a comparison in mapsource: The map compiled from .mp did not exhibit this error. I have attached screen shots for comparison: osm-oneway.PNG -> compiled from .osm osm-oneway-mp.PNG -> compiled from .mp The rather crudely drawn red arrow indicates the one-way direction. Is there any other information which would be helpful? Hope this helps.
On Feb 18, 2009, at 13:07, Clinton Gladstone wrote:
On Wed, Feb 18, 2009 at 12:41 PM, Robert Vollmert <rvollmert-lists@gmx.net> wrote:
Thanks for the report. The oneway street is just one way in the .osm, right?
Could you try going via .mp? It's unlikely to make a difference, but that way we could narrow it down somewhat.
I just happened to notice this exact same error last night while driving home. I had an .mp version of the same map handy, and did a comparison in mapsource: The map compiled from .mp did not exhibit this error.
The obvious difference between the .mp and .osm readers is that the "direction indicator" flag is not being set. Does the following patch help? Though with the behaviour you're reporting, it seems more likely that something goes wrong for just some of the arcs, and not the entire road... --- osmstyle/StyledConverter.java (revision 899) +++ osmstyle/StyledConverter.java (working copy) @@ -357,8 +357,11 @@ // set road parameters. road.setRoadClass(gt.getRoadClass()); - road.setOneway(line.isDirection()); - + if (way.isBoolTag("oneway")) { + road.setOneway(true); + road.setDirIndicator(true); + } + // maxspeed attribute overrides default for road type String maxSpeed = way.getTag("maxspeed");
On Wed, Feb 18, 2009 at 1:39 PM, Robert Vollmert <rvollmert-lists@gmx.net> wrote:
The obvious difference between the .mp and .osm readers is that the "direction indicator" flag is not being set. Does the following patch help?
I applied your patch and recompiled the map: in my initial tests the error does not occur. Thanks! I will retest more thoroughly and report my results. Cheers.
On Wed, Feb 18, 2009 at 1:39 PM, Robert Vollmert <rvollmert-lists@gmx.net> wrote:
The obvious difference between the .mp and .osm readers is that the "direction indicator" flag is not being set. Does the following patch help?
I have done a more thorough test of my particular routing problem: this patch does indeed seem to completely resolve the error. Later on, I'll try to test in other areas, both using Mapsource and my GPS. Thanks and Cheers!
I have done a more thorough test of my particular routing problem: this patch does indeed seem to completely resolve the error.
That's good news. I'm mystified as to why it is necessary to set dirindicator because on my etrex, routing appears to use one-way streets as expected without dirindicator being set - very odd. Cheers, Mark
On Wed, Feb 18, 2009 at 3:04 PM, Mark Burton <markb@ordern.com> wrote:
I'm mystified as to why it is necessary to set dirindicator because on my etrex, routing appears to use one-way streets as expected without dirindicator being set - very odd.
Would you still like me to post the OSM source for the region? A +/- 1km extract could be a little too large to comfortably send to the mailing list. Cheers.
Hi Clinton,
On Wed, Feb 18, 2009 at 3:04 PM, Mark Burton <markb@ordern.com> wrote:
I'm mystified as to why it is necessary to set dirindicator because on my etrex, routing appears to use one-way streets as expected without dirindicator being set - very odd.
Would you still like me to post the OSM source for the region? A +/- 1km extract could be a little too large to comfortably send to the mailing list.
No, I'm sorry, I was speaking rubbish. The etrex does show the problem. I think what's happening here is that without dirindicator being set, the gps will not route INTO a oneway street the wrong way. But if the route STARTS in a oneway street, it will route OUT using the wrong direction unless dirindicator is set. If you ask me, that's pretty dumb behaviour by the gps. Cheers, Mark
On Feb 18, 2009, at 15:04, Mark Burton wrote:
I'm mystified as to why it is necessary to set dirindicator because on my etrex, routing appears to use one-way streets as expected without dirindicator being set - very odd.
What's dirindicator supposed to do, anyway? I'm thinking that maybe the dirindicator and one-way flags shouldn't be treated as independent flags, just that some applications check NET for oneway-ness, while others check NOD. Cheers Robert
Hi Robert,
What's dirindicator supposed to do, anyway? I'm thinking that maybe the dirindicator and one-way flags shouldn't be treated as independent flags, just that some applications check NET for oneway-ness, while others check NOD.
This is what the cGPSMapper doc says about it: DirIndicator=# Direction indicator, only for streets, highways, etc. 0 no direction 1 the GPS will show direction of the road (calculated internally by GPS) Default = 0 When I originally read that, I thought that it was saying something about how the gps displayed the road, rather than affecting the routing logic. I append a new version of the patch - seems rather a lot of flags being set! Cheers, Mark
Hello Mark, A test with r906 showed that the problem is fixed. thanks for your efforts, Stefan On Wednesday 18 February 2009, Mark Burton wrote:
I append a new version of the patch - seems rather a lot of flags being set!
Duh! I just spotted the deliberate mistake in that patch - new version attached.
On Feb 18, 2009, at 15:25, Mark Burton wrote:
What's dirindicator supposed to do, anyway? I'm thinking that maybe the dirindicator and one-way flags shouldn't be treated as independent flags, just that some applications check NET for oneway-ness, while others check NOD.
This is what the cGPSMapper doc says about it:
DirIndicator=# Direction indicator, only for streets, highways, etc. 0 no direction 1 the GPS will show direction of the road (calculated internally by GPS) Default = 0
When I originally read that, I thought that it was saying something about how the gps displayed the road, rather than affecting the routing logic.
Yes, that's what I thought, too. It turns out we're writing direction info in three places: 1. a flag in RGN (Polyline.FLAG_DIR) 2. a flag in NET (RoadDef.FLAG_DIR_INDICATOR) 3. a flag in Table A in NOD (RoadDef.TABA_FLAG_ONEWAY) Maybe I got the DirIndicator<->NET connection wrong, and DirIndicator should just be set on the polyline. Since the polyline is what's rendered, that would make a lot of sense. Then 2. and 3. would both be oneway-ness. I'll make the change. Cheers Robert
Hi, On Wed, Feb 18, 2009 at 4:19 PM, Robert Vollmert <rvollmert-lists@gmx.net> wrote:
On Feb 18, 2009, at 15:04, Mark Burton wrote:
I'm mystified as to why it is necessary to set dirindicator because on my etrex, routing appears to use one-way streets as expected without dirindicator being set - very odd.
What's dirindicator supposed to do, anyway? I'm thinking that maybe the
Dir Indicator is necessery for finding the position on the road. Street A ----->----->---->------- Street A -----<-----<----<------- Where Street A is defined by two separate lines which are very close, like in a road w/ fence in the middle. They are close and when the dir indicator is set it helps to find on correct line you are when moving. So you don't see yourself on the opposite direction lane. -- have fun, alex
On Feb 18, 2009, at 15:44, Alexander Atanasov wrote:
Dir Indicator is necessery for finding the position on the road.
"Dir Indicator" is the flag 0x02 in NET for you?
Street A ----->----->---->------- Street A -----<-----<----<-------
Where Street A is defined by two separate lines which are very close, like in a road w/ fence in the middle. They are close and when the dir indicator is set it helps to find on correct line you are when moving. So you don't see yourself on the opposite direction lane.
Ok, that's another point where orientation comes in. But we might as well call this flag oneway, right? Cheers Robert
Hi. On Wed, Feb 18, 2009 at 5:00 PM, Robert Vollmert <rvollmert-lists@gmx.net> wrote:
On Feb 18, 2009, at 15:44, Alexander Atanasov wrote:
Dir Indicator is necessery for finding the position on the road.
"Dir Indicator" is the flag 0x02 in NET for you?
I mean the polyline flag. As for the flags in NET i think they are either shortcuts/hints for the whole road flags or they can be used for routing if there is no NOD data.
Street A ----->----->---->------- Street A -----<-----<----<-------
Where Street A is defined by two separate lines which are very close, like in a road w/ fence in the middle. They are close and when the dir indicator is set it helps to find on correct line you are when moving. So you don't see yourself on the opposite direction lane.
Ok, that's another point where orientation comes in. But we might as well call this flag oneway, right?
Yes. it's the same thing, different names. -- have fun, alex
participants (7)
-
Alexander Atanasov -
Clinton Gladstone -
Johann Gail -
Mark Burton -
Robert Vollmert -
Stefan Wenk -
Steve Ratcliffe