Re: [mkgmap-dev] [PATCH v3] heed the through_route relation when adjusting turn headings
Mark Burton wrote: That northeasterly-bound section of B4290 isn't a single way because of bus-route issues, but I made a "through_route" relation to span across the junction "just in case". It made no difference. But as a left turn isn't actually allowed there, perhaps the GPS doesn't bother to tell you to turn right as it "knows" you can't turn left? Don't think so. On a different junction last night I got told to turn left on joining a dual-carriageway from a side road when there was no alternative. Steve ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [PATCH v3] heed the through_route relation when adjusting turn headings
Hi Steve, > Unless you know better, I'd say it was time or nearly time to merge that > branch back to trunk. Agreed. > The only slightly odd behaviour for me is at: > http://www.openstreetmap.org/?mlat=51.612512&mlon=-3.961642&zoom=18&layers=B000FTF > > ..where, if I approach on the southern stub from the traffic lights on > Oystermouth Rd (A4067) I'd expect to be told "turn right" onto the > oneway section of B4290. But I get no announcement. > > That northeasterly-bound section of B4290 isn't a single way because of > bus-route issues, but I made a "through_route" relation to span across > the junction "just in case". It made no difference. But as a left turn isn't actually allowed there, perhaps the GPS doesn't bother to tell you to turn right as it "knows" you can't turn left? Cheers, Mark ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [PATCH v3] heed the through_route relation when adjusting turn headings
Mark Burton wrote: Hi Steve, If that comes up today, I can test it tonight. Thanks in advance. A v4 patch was posted yesterday, here it is again. I wasn't paying attention - you're quite right, it was already posted. Whatever - I tried it last night and it was fine. Thank you. Unless you know better, I'd say it was time or nearly time to merge that branch back to trunk. The only slightly odd behaviour for me is at: http://www.openstreetmap.org/?mlat=51.612512&mlon=-3.961642&zoom=18&layers=B000FTF ..where, if I approach on the southern stub from the traffic lights on Oystermouth Rd (A4067) I'd expect to be told "turn right" onto the oneway section of B4290. But I get no announcement. That northeasterly-bound section of B4290 isn't a single way because of bus-route issues, but I made a "through_route" relation to span across the junction "just in case". It made no difference. Steve ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [PATCH v3] heed the through_route relation when adjusting turn headings
Hi Steve,
> If that comes up today, I can test it tonight. Thanks in advance.
A v4 patch was posted yesterday, here it is again.
Cheers,
Mark
diff --git a/src/uk/me/parabola/imgfmt/app/net/RoadDef.java b/src/uk/me/parabola/imgfmt/app/net/RoadDef.java
index de87495..e6a187e 100644
--- a/src/uk/me/parabola/imgfmt/app/net/RoadDef.java
+++ b/src/uk/me/parabola/imgfmt/app/net/RoadDef.java
@@ -555,6 +555,10 @@ public class RoadDef implements Comparable {
nod2Flags |= (speed << 1);
}
+ public int getRoadSpeed() {
+ return tabAInfo & 7;
+ }
+
public void setOneway() {
tabAInfo |= TABA_FLAG_ONEWAY;
netFlags |= NET_FLAG_ONEWAY;
diff --git a/src/uk/me/parabola/imgfmt/app/net/RouteNode.java b/src/uk/me/parabola/imgfmt/app/net/RouteNode.java
index 45d6010..c01f7a9 100644
--- a/src/uk/me/parabola/imgfmt/app/net/RouteNode.java
+++ b/src/uk/me/parabola/imgfmt/app/net/RouteNode.java
@@ -67,6 +67,7 @@ public class RouteNode implements Comparable {
private final CoordNode coord;
private char latOff;
private char lonOff;
+ private List throughRoutes;
// this is for setting destination class on arcs
// we're taking the maximum of roads this node is
@@ -295,18 +296,8 @@ public class RouteNode implements Comparable {
private static boolean possiblySameRoad(RouteArc raa, RouteArc rab) {
- if(raa == rab) {
- // the arcs are the same object
- return true;
- }
-
RoadDef rda = raa.getRoadDef();
RoadDef rdb = rab.getRoadDef();
- if(rda == rdb) {
- // the arcs share the same RoadDef
- return true;
- }
-
boolean bothArcsNamed = false;
for(Label laba : rda.getLabels()) {
if(laba != null && laba.getOffset() != 0) {
@@ -395,17 +386,74 @@ public class RouteNode implements Comparable {
// determine the outgoing arc that is likely to be the
// same road as the incoming arc
RouteArc outArc = null;
-for(RouteArc oa : arcs) {
- if(oa.getDest() != inArc.getSource()) {
- // this arc is not going to the same node as
- // inArc came from
- if((oa.isForward() || !oa.getRoadDef().isOneway()) &&
- possiblySameRoad(inArc, oa)) {
- outArc = oa;
+
+if(throughRoutes != null) {
+ // through_route relations have the highest precedence
+ for(RouteArc[] pair : throughRoutes) {
+ if(pair[0] == inArc) {
+ outArc = pair[1];
+ log.info("Found through route from " + inArc.getRoadDef() + " to " + outArc.getRoadDef());
break;
}
}
}
+
+if(outArc == null) {
+ // next, if oa has the same RoadDef as inArc, it's
+ // definitely the same road
+ for(RouteArc oa : arcs) {
+ if(oa.getDest() != inArc.getSource()) {
+ // this arc is not going to the same node as
+ // inArc came from
+ if(oa.getRoadDef() == inArc.getRoadDef()) {
+outArc = oa;
+break;
+ }
+ }
+ }
+}
+
+if(outArc == null) {
+ // next, although the RoadDefs don't match, use
+ // possiblySameRoad() to see if the road
+ // labels (names/refs) match
+ for(RouteArc oa : arcs) {
+ if(oa.getDest() != inArc.getSource()) {
+ // this arc is not going to the same node as
+ // inArc came from
+ if((oa.isForward() || !oa.getRoadDef().isOneway()) &&
+ possiblySameRoad(inArc, oa)) {
+outArc = oa;
+break;
+ }
+ }
+ }
+}
+
+if(outArc == null) {
+ // last ditch attempt to find the outgoing arc -
+ // try and find a single arc that has the same
+ // road class and speed as the incoming arc
+ int inArcClass = inArc.getRoadDef().getRoadClass();
+ int inArcSpeed = inArc.getRoadDef().getRoadSpeed();
+ for(RouteArc oa : arcs) {
+ if(oa.getDest() != inArc.getSource() &&
+ oa.getRoadDef().getRoadClass() == inArcClass &&
+ oa.getRoadDef().getRoadSpeed() == inArcSpeed) {
+ if(outArc != null) {
+// multiple arcs have the same road
+// class as the incoming arc so don't
+// use any of them as the outgoing arc
+outArc = null;
+break;
+ }
+ outArc = oa;
+ }
+ }
+ if(outArc != null)
+ log.info("Matched outgoing arc " + outArc.getRoadDef() + " to " + inArc.getRoadDef() + " using road class (" + inArcClass + ") and speed (" + inArcSpeed + ")");
+}
+
// if we did not find the outgoing arc, give up with
// this incoming arc
if(outArc == null) {
@@ -449,12 +497,6 @@ public class RouteNode implements Comparable {
continue;
}
- if(possiblySameRoad(inArc, otherArc) ||
- possiblySameRoad(outArc, otherArc)) {
- // not obviously a different road so give up
- continue;
- }
-
if(inArc.getRoadDef().isLinkRoad() &&
otherArc.getRoadDef().isLinkRoad()) {
// it's a link road leaving a link road so
@@ -483,9 +525,12 @@ public class RouteNode implements Comparable {
if((mask & ATH_OUTGOING) != 0 &&
outToOtherDelta < m
Re: [mkgmap-dev] [PATCH v3] heed the through_route relation when adjusting turn headings
Mark Burton wrote: ..if you drive south-east on Kilfield Road... I have just tried routing on that road and mapsource did not give me a "turn right" at that junction. However, I have tweaked the code as it could get confused as to which is the through route as all the roads at that junction have the same name. Yeah, exactly. And I can show you quite a few other residential roads where the same thing happens. So now the one-piece road will take precedence over the stub even though they have the same name. I will post a new patch shortly, please see if it does the right thing there. If that comes up today, I can test it tonight. Thanks in advance. 2) Can we invent some way to mark up traffic lanes [...] one day we might find how "lane assist" works in Garmin maps and be able to code for it properly. I wonder if marking a lane like this one as "highway=primary" "primary=traffic_lane" "ref=A4076" (etc) would be useful and desirable and would you be able to handle it anyway? This is a difficult situation to handle. A problem is that if you don't tweak the heading for the link road you will then get "keep left" instructions for each exit you approach. It currently does a good job of not telling you to "keep left" on motorways and trunk roads and I would prefer that it stays that way. No argument there. That's why I suggest some sort of mark-up for the traffic lanes situation. It's a special-case, and another thing the mark-up would help with is to fix the complaints that "keepright" gives for junctions like that. Now, there probably is an attitude out there that I shouldn't be doing this in the first place, but on approaching complex multi-lane junctions it would be good for the GPS to generate "get in lane" instructions. The "official" maps often do, and we should too if our maps are to be considered seriously. If we do generate mark-up, we'll need to invent something that's GPS-independent of course, so it can be used by the Android and TomTom and other map projects out there. More thought required... Yup! Steve ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [PATCH v3] heed the through_route relation when adjusting turn headings
Hi Steve, Thanks for the feedback. > Mark - I've been giving the 'through_route' patch a bit of use, and I > must say it does a great job of allowing the mapper to 'fix' those > annoying junctions where there was no way for mkgmap to decide the road > priority. Good. > I have a couple of issues still, and a few suggestions: > > 1) Could you arrange for mkgmap to honour the "continuity" of a drawn > way? In other words, if a way with a given name has a bend in it, and a > stub of the same road class and same road name makes a "T" junction with > it, then assume that the continuously-drawn way is the through-route? > Here's an example: > > http://www.openstreetmap.org/?mlat=51.577273&mlon=-4.041473&zoom=17&layers=B000FTF > > ..if you drive south-east on Kilfield Road, then as you approach the > marker you'll be told to "turn right" where really the entire length of > Kilfield Road is drawn as a single way, with the smaller stub being > another way in its own right. I don't know about other mappers, but I > know a *lot* of cases (mostly in residential areas) where a long curve > of road had small stubs sticking off it, and they'll all generate bogus > instructions if this isn't dealt with. I have just tried routing on that road and mapsource did not give me a "turn right" at that junction. However, I have tweaked the code as it could get confused as to which is the through route as all the roads at that junction have the same name. So now the one-piece road will take precedence over the stub even though they have the same name. I will post a new patch shortly, please see if it does the right thing there. > 2) Can we invent some way to mark up traffic lanes? Here's a case in point: > > http://www.openstreetmap.org/?mlat=51.61219&mlon=-3.961323&zoom=18&layers=B000FTF > > You probably want to look at the area in Potlatch to see what's > happening. Yes - I know I'm probably rather stretching the rules here, > but the idea was that if a driver approaches on the A4067 from the east, > wanting to take the right turn onto the stub of B4290 and thence to > follow the B4290 towards the northeast, then he'd get a "keep right" > instruction about 150m before the junction itself (that's where a > dedicated traffic lane starts) and then get a "turn right" at the > junction itself, followed by another "turn right" 30m later to the north > as he joins the northeast-bound B4290. > > It used to work like that, but now I get a "turn right" (not "keep > right") at 150m short of the junction because the heading of the > junction has been tweaked. If we could mark up traffic lanes it might > allow you to maintain that useful "keep right" where the lane branches > off. Additionally, one day we might find how "lane assist" works in > Garmin maps and be able to code for it properly. > > I wonder if marking a lane like this one as "highway=primary" > "primary=traffic_lane" "ref=A4076" (etc) would be useful and desirable > and would you be able to handle it anyway? This is a difficult situation to handle. A problem is that if you don't tweak the heading for the link road you will then get "keep left" instructions for each exit you approach. It currently does a good job of not telling you to "keep left" on motorways and trunk roads and I would prefer that it stays that way. More thought required... Cheers, Mark ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [PATCH v3] heed the through_route relation when adjusting turn headings
Mark Burton wrote: > v3 - bug fixes: > > now ignores through_route relations if the junction is outside of the > tile's bounding box > > should no longer think that ways that have been split do not start > or end at the junction. > > Mark - I've been giving the 'through_route' patch a bit of use, and I must say it does a great job of allowing the mapper to 'fix' those annoying junctions where there was no way for mkgmap to decide the road priority. I have a couple of issues still, and a few suggestions: 1) Could you arrange for mkgmap to honour the "continuity" of a drawn way? In other words, if a way with a given name has a bend in it, and a stub of the same road class and same road name makes a "T" junction with it, then assume that the continuously-drawn way is the through-route? Here's an example: http://www.openstreetmap.org/?mlat=51.577273&mlon=-4.041473&zoom=17&layers=B000FTF ..if you drive south-east on Kilfield Road, then as you approach the marker you'll be told to "turn right" where really the entire length of Kilfield Road is drawn as a single way, with the smaller stub being another way in its own right. I don't know about other mappers, but I know a *lot* of cases (mostly in residential areas) where a long curve of road had small stubs sticking off it, and they'll all generate bogus instructions if this isn't dealt with. 2) Can we invent some way to mark up traffic lanes? Here's a case in point: http://www.openstreetmap.org/?mlat=51.61219&mlon=-3.961323&zoom=18&layers=B000FTF You probably want to look at the area in Potlatch to see what's happening. Yes - I know I'm probably rather stretching the rules here, but the idea was that if a driver approaches on the A4067 from the east, wanting to take the right turn onto the stub of B4290 and thence to follow the B4290 towards the northeast, then he'd get a "keep right" instruction about 150m before the junction itself (that's where a dedicated traffic lane starts) and then get a "turn right" at the junction itself, followed by another "turn right" 30m later to the north as he joins the northeast-bound B4290. It used to work like that, but now I get a "turn right" (not "keep right") at 150m short of the junction because the heading of the junction has been tweaked. If we could mark up traffic lanes it might allow you to maintain that useful "keep right" where the lane branches off. Additionally, one day we might find how "lane assist" works in Garmin maps and be able to code for it properly. I wonder if marking a lane like this one as "highway=primary" "primary=traffic_lane" "ref=A4076" (etc) would be useful and desirable and would you be able to handle it anyway? Steve ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
