Re: [Tagging] Feature Proposal - RFC - junction=intersection
On 10/07/2020 16.38, Jarek Piórkowski wrote: On Fri, 10 Jul 2020 at 15:53, Matthew Woehlke wrote: [problem description elided; see archives] Yeah that's a problem. But since OSM would have to be changed to add junction=intersection tags anyway, isn't it better to use the established method of tagging with one traffic signal per direction at the stop line, as suggested in the wiki https://wiki.openstreetmap.org/wiki/Tag:highway=traffic_signals#Tag_all_incoming_ways ? Yes, and somewhat irrelevant. That's not the only problem that junction=intersection solves. -- Matthew ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - junction=intersection
> On Jul 10, 2020, at 9:26 AM, Matthew Woehlke wrote: > > On 10/07/2020 11.24, Peter Elderson wrote: >> Well, if you do a couple of intersections it's no big deal, but if every >> intersection would need this and it breaks relations, no matter whose fault >> it is, it is a problem. Then it's not just modeling, but forced repair >> work. In the old days the wiki said you could put a highway=stop or highway=give_way node on a way and the data consumer would determine the nearest intersection and just do the right thing. I mapped several thousand, yes thousand, stop signs that way. Later it was decided that each of those nodes should also have a direction=forward or direction=backward tag as well. Years later, I am still updating those highway=stop nodes as the various QA tools nag that I am responsible for miss tagging them. So I am pretty sensitive to changing tagging norms on intersections. That change in tagging was also annoying because at the time the direction tag was defined and used for showing the bearing, in degrees, something (cave opening, adit, etc.) was facing. So we ended up with two separate semantics for the direction tag depending on the type of node. And an inconsistency between how stop and yield sign directions were specified (“direction=*”) and how traffic light directions were specified (“traffic_signals:direction=*”). > > Sure, but my point was that I don't think my proposal changes anything here, > since someone (myself, for example) might already split ways at intersections > for other reasons. > >> May be worth it, but I would like to know that at proposal time, not >> by discovering all routes and turn restrictions are broken. > > That's fair. I'm not actually sure offhand what happens when you split a way > at or near an intersection, although I would hope that editors can update the > relations correctly. This is probably more of an issue with intersections > where turn lanes are separately modeled, and I wonder how many of those > aren't already split as they would need to be. > > That said, I think it makes sense to add a note asking editors to be mindful > of such things. I'll add some wordage to the proposal. With respect to what happens when a way is split near an intersection, I have been using the “tag all incoming ways” [1] method for mapping intersections. On two way roads leading into an intersection current tagging asks for a direction=* tag on stop and yield signs and for a traffic_signals:direction=* tag on traffic signals. I have seen a few intersections where the limit line (where you would place the stop sign or traffic light node) exactly on top of a the transition to a bridge. This leads me to wonder what the semantics of “direction=forward | backward” or “traffic_signals:direction=forward | backward” are if the node is at the change of ways, especially if the ways have different directions. I haven’t seen this defined. But I think it is a situation that could be come more common if all ways are split where they enter an intersection so some thought should be given to that. Cheers! Tod [1] https://wiki.openstreetmap.org/wiki/Tag:highway%3Dtraffic_signals#Tag_all_incoming_ways signature.asc Description: Message signed with OpenPGP ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - junction=intersection
sent from a phone > On 10. Jul 2020, at 21:52, Matthew Woehlke wrote: > > I have to strongly disagree. Consider an intersection of dual carriageways > (so, four intersection nodes) where signals are tagged on the intersection > nodes. that’s the problem, they should not be tagged on the intersection nodes in this case. If you tag them shortly before the intersection there is no issue with the traffic lights. That’s what I meant to say. It’s possible to get it right with both methods. Cheers Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - junction=intersection
On Fri, 10 Jul 2020 at 15:53, Matthew Woehlke wrote: > On 10/07/2020 15.01, Martin Koppenhoefer wrote: > >> On 10. Jul 2020, at 16:17, Matthew Woehlke > >> wrote: > >> My use case isn't the only one that has issues with this sort of > >> thing; routers can "see" more traffic lights than actually exist > >> and can (so I hear, anyway) give directions that are potentially > >> confusing. > > > > this is a different issue though, it depends how the traffic lights > > are mapped (the way the junction is represented does have influence > > how the traffic lights are mapped, but neither way leads necessarily > > to a wrong number of traffic lights). > > I have to strongly disagree. Consider an intersection of dual > carriageways (so, four intersection nodes) where signals are tagged on > the intersection nodes. Please explain how a tool is supposed to > determine whether a vehicle passing "straight through" the intersection > will encounter one or two signals. > > Now take that same intersection and plop it into a dense urban area > where there really *are* four separate intersections and explain how the > same tool is supposed to know when that's the case. Yeah that's a problem. But since OSM would have to be changed to add junction=intersection tags anyway, isn't it better to use the established method of tagging with one traffic signal per direction at the stop line, as suggested in the wiki https://wiki.openstreetmap.org/wiki/Tag:highway=traffic_signals#Tag_all_incoming_ways ? ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - junction=intersection
On 10/07/2020 15.01, Martin Koppenhoefer wrote: On 10. Jul 2020, at 16:17, Matthew Woehlke wrote: My use case isn't the only one that has issues with this sort of thing; routers can "see" more traffic lights than actually exist and can (so I hear, anyway) give directions that are potentially confusing. this is a different issue though, it depends how the traffic lights are mapped (the way the junction is represented does have influence how the traffic lights are mapped, but neither way leads necessarily to a wrong number of traffic lights). I have to strongly disagree. Consider an intersection of dual carriageways (so, four intersection nodes) where signals are tagged on the intersection nodes. Please explain how a tool is supposed to determine whether a vehicle passing "straight through" the intersection will encounter one or two signals. Now take that same intersection and plop it into a dense urban area where there really *are* four separate intersections and explain how the same tool is supposed to know when that's the case. -- Matthew ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - junction=intersection
sent from a phone > On 10. Jul 2020, at 16:17, Matthew Woehlke wrote: > > My use case isn't the only one that has issues with this sort of thing; > routers can "see" more traffic lights than actually exist and can (so I hear, > anyway) give directions that are potentially confusing. this is a different issue though, it depends how the traffic lights are mapped (the way the junction is represented does have influence how the traffic lights are mapped, but neither way leads necessarily to a wrong number of traffic lights). Cheers Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - junction=intersection
For illustrative purposes, I went ahead and tagged https://www.openstreetmap.org/way/175473372. (I chose this intersection because the way was already split, so the only edit needed was to add the tag.) On 10/07/2020 10.15, Matthew Woehlke wrote: As some of you may recall, I'm working on a project to do traffic simulation with the help of OSM data and SUMO¹. One of the issues that SUMO has is that the typical method of modeling intersections (which I don't propose to change, mostly) results in SUMO thinking there are multiple intersections where there should only be one. For example, intersections of two dual carriageways produces four intersections and makes the turns much sharper than in reality. My use case isn't the only one that has issues with this sort of thing; routers can "see" more traffic lights than actually exist and can (so I hear, anyway) give directions that are potentially confusing. Intersection modeling is a long-standing issue that has had multiple previous proposals. The major two prior proposals of which I'm aware are to map the 'footprint' of the intersection as an area, or to create relations to map the intersection. Both are difficult, both to model, and for tools to parse. The area proposal has potential rendering issues. I am proposing² a *much* simpler alternative, which is to simply tag the portions of a road that are "part of" an intersection (i.e. the 'm', 'n', 'p', 'q' segments of https://wiki.openstreetmap.org/wiki/File:Doublejunction.svg) with junction=intersection. This is straight-forward to model, and I believe solves most of the issues for a majority of affected intersections. (Exceptions likely exist, but 'perfect' is the enemy of 'good', and right now we're at 'bad'.) Comments would be appreciated! Also, should I start just doing this for the areas I'm trying to use for my project, or is it better to wait for some degree of consensus? (¹ https://www.eclipse.org/sumo/) (² https://wiki.openstreetmap.org/wiki/Proposed_features/junction%3Dintersection) ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - junction=intersection
On 10/07/2020 12.57, Tod Fitch wrote: In the old days the wiki said you could put a highway=stop or highway=give_way node on a way and the data consumer would determine the nearest intersection and just do the right thing. I mapped several thousand, yes thousand, stop signs that way. Later it was decided that each of those nodes should also have a direction=forward or direction=backward tag as well. Years later, I am still updating those highway=stop nodes as the various QA tools nag that I am responsible for miss tagging them. So I am pretty sensitive to changing tagging norms on intersections. That's... interestingly ironic. The problem is you *cannot* correctly tag a direction on such entities where assigned to the intersection nodes of a dual carriageway. My proposal would not only fix that, it would obviate the need for specifying a direction. Going back to relations, is it even *possible* to correctly tag a relation on a way that isn't split at the 'via' node? (How does the relation otherwise know to which side of the way it applies?) If the way already *must* be split at the 'via' node, I don't think splitting it downstream will break the relation unless the editor is dumb as rocks. (That is, I think the editor can reliably repair the relation automatically.) With respect to what happens when a way is split near an intersection, I have been using the “tag all incoming ways” [1] method for mapping intersections. Heh... I missed (or had forgotten about) that. Yes, that's what I'm doing, also. It solves the signals/signage issue (and likewise makes it sometimes unnecessary to add directionality), but not other issues with tools not recognizing intersections as single logical entities. I have seen a few intersections where the limit line (where you would place the stop sign or traffic light node) exactly on top of a the transition to a bridge. This leads me to wonder what the semantics of “direction=forward | backward” or “traffic_signals:direction=forward | backward” are if the node is at the change of ways, especially if the ways have different directions. Broken, I would expect, if the meeting ways don't have the same direction :-). (Fortunately, it should be easy for tools to flag this...) If they're in the _same_ direction, it would apply to the way that is "entering" (or "exiting") the node, i.e. it's well defined. But I think it is a situation that could be come more common if all ways are split where they enter an intersection so some thought should be given to that. I think I've already done that? One of the proposed semantics is that "signals do not apply to a way which is tagged junction=intersection". That is, it is well defined to which edge a signal/signage/etc. applies *without* needing to specify a direction. (This is implicit, because AFAIK signals/signs never apply *inside* of intersections, but to the *boundaries* of intersections. Once you're *in* an intersection, the intent is that you *get out ASAP*.) -- Matthew ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - junction=intersection
On 10/07/2020 12.22, Clifford Snow wrote:
Interesting suggestion. The sumo github page doesn't appear to have any
open issues that involve OSM and intersections that I could find. (I only
looked at intersection issue titles) Has this been reported to the sumo
developers? Sumo documentation does suggest fixing OSM issues but other
than that it seems to indicate that OSM data is suitable for use with their
software.
I haven't reported anything yet, but (obviously?) it is my intention if
this gains any traction to improve SUMO to automatically merge
intersections based on this tag. That said, if you watch their
*tutorial* (it's over an hour long), there is at least one example where
the presenter shows an instance of this issue, so it *is* known to the
community. I'm not sure if anyone else has had the idea to specifically
annotate these in OSM in order to be able to better fix up such
intersections automatically.
For my specific use case, it's moderately important to be able to
convert OSM data into SUMO networks in a fully automated and
deterministic manner.
Another issue, that isn't really OSM's fault, is that SUMO likes to add
intersections wherever a way is split, even though only two edges come
together. I don't think OSM needs to change anything there, however,
except perhaps that it might be desirable to mark nodes where a U-turn
is specifically legal.
You mention that the duplicate traffic signals are a problem but I don't
understand from your proposal how traffic signals should be tagged in your
proposal. Could you update your proposal to include how they are to be
tagged as part of the intersection.
That's because the proposal isn't proposing to change how signals are
tagged. Rather, the objective is to make it so that "the existing way"
("each [intersection] node is tagged as a traffic signal") Just Works™
with tools: "signals do not apply to a way which is tagged
junction=intersection".
*Independently*, I am leaning toward suggesting to tag signals at the
'stop here' line rather than on the intersection nodes (which also
solves the signals aspect of the problem in a different manner), but IMO
that is orthogonal. See e.g.
https://www.openstreetmap.org/node/7695739446. (Also, if this proposal
is approved, that change may or may not be necessary or desirable. I
think the 'stop here' lines should be tagged in *some* manner, but with
junction=intersection, it may be that a new way to tag 'stop here' lines
is desired and leaving the signals on the intersection nodes is
preferred. At that point, we're getting into arguing about tagging where
the signal *applies* vs. where the actual signal lamp is physically
located.)
--
Matthew
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - junction=intersection
On 10/07/2020 11.24, Peter Elderson wrote: Well, if you do a couple of intersections it's no big deal, but if every intersection would need this and it breaks relations, no matter whose fault it is, it is a problem. Then it's not just modeling, but forced repair work. Sure, but my point was that I don't think my proposal changes anything here, since someone (myself, for example) might already split ways at intersections for other reasons. May be worth it, but I would like to know that at proposal time, not by discovering all routes and turn restrictions are broken. That's fair. I'm not actually sure offhand what happens when you split a way at or near an intersection, although I would hope that editors can update the relations correctly. This is probably more of an issue with intersections where turn lanes are separately modeled, and I wonder how many of those aren't already split as they would need to be. That said, I think it makes sense to add a note asking editors to be mindful of such things. I'll add some wordage to the proposal. -- Matthew ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - junction=intersection
Matthew, Interesting suggestion. The sumo github page doesn't appear to have any open issues that involve OSM and intersections that I could find. (I only looked at intersection issue titles) Has this been reported to the sumo developers? Sumo documentation does suggest fixing OSM issues but other than that it seems to indicate that OSM data is suitable for use with their software. You mention that the duplicate traffic signals are a problem but I don't understand from your proposal how traffic signals should be tagged in your proposal. Could you update your proposal to include how they are to be tagged as part of the intersection. Best, Clifford On Fri, Jul 10, 2020 at 7:15 AM Matthew Woehlke wrote: > As some of you may recall, I'm working on a project to do traffic > simulation with the help of OSM data and SUMO¹. > > One of the issues that SUMO has is that the typical method of modeling > intersections (which I don't propose to change, mostly) results in SUMO > thinking there are multiple intersections where there should only be > one. For example, intersections of two dual carriageways produces four > intersections and makes the turns much sharper than in reality. > > My use case isn't the only one that has issues with this sort of thing; > routers can "see" more traffic lights than actually exist and can (so I > hear, anyway) give directions that are potentially confusing. > Intersection modeling is a long-standing issue that has had multiple > previous proposals. > > The major two prior proposals of which I'm aware are to map the > 'footprint' of the intersection as an area, or to create relations to > map the intersection. Both are difficult, both to model, and for tools > to parse. The area proposal has potential rendering issues. > > I am proposing² a *much* simpler alternative, which is to simply tag the > portions of a road that are "part of" an intersection (i.e. the 'm', > 'n', 'p', 'q' segments of > https://wiki.openstreetmap.org/wiki/File:Doublejunction.svg) with > junction=intersection. This is straight-forward to model, and I believe > solves most of the issues for a majority of affected intersections. > (Exceptions likely exist, but 'perfect' is the enemy of 'good', and > right now we're at 'bad'.) > > Comments would be appreciated! > > Also, should I start just doing this for the areas I'm trying to use for > my project, or is it better to wait for some degree of consensus? > > (¹ https://www.eclipse.org/sumo/) > > (² > > https://wiki.openstreetmap.org/wiki/Proposed_features/junction%3Dintersection > ) > > -- > Matthew > > ___ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging > -- @osm_washington www.snowandsnow.us OpenStreetMap: Maps with a human touch ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - junction=intersection
Well, if you do a couple of intersections it's no big deal, but if every intersection would need this and it breaks relations, no matter whose fault it is, it is a problem. Then it's not just modeling, but forced repair work. May be worth it, but I would like to know that at proposal time, not by discovering all routes and turn restrictions are broken. Just a consideration, if it doesn't break anything it's fine. Best, Peter Elderson Op vr 10 jul. 2020 om 16:50 schreef Matthew Woehlke < mwoehlke.fl...@gmail.com>: > On 10/07/2020 10.36, Peter Elderson wrote: > > Question: does it break anything? I am thinking about existing relations > of > > various kinds. > > If splitting ways breaks relations, well, a) that's an editor problem, > and b) I've already been breaking those left and right from splitting > ways to improve accuracy of lane information. > > I don't see how it would break the *ability* to model anything, however. > Given the above, I don't see how it could be meaningfully *harmful*. > > -- > Matthew > > ___ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging > ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - junction=intersection
On 10/07/2020 10.36, Peter Elderson wrote: Question: does it break anything? I am thinking about existing relations of various kinds. If splitting ways breaks relations, well, a) that's an editor problem, and b) I've already been breaking those left and right from splitting ways to improve accuracy of lane information. I don't see how it would break the *ability* to model anything, however. Given the above, I don't see how it could be meaningfully *harmful*. -- Matthew ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - junction=intersection
Question: does it break anything? I am thinking about existing relations of various kinds. Best, Peter Elderson Op vr 10 jul. 2020 om 16:17 schreef Matthew Woehlke < mwoehlke.fl...@gmail.com>: > As some of you may recall, I'm working on a project to do traffic > simulation with the help of OSM data and SUMO¹. > > One of the issues that SUMO has is that the typical method of modeling > intersections (which I don't propose to change, mostly) results in SUMO > thinking there are multiple intersections where there should only be > one. For example, intersections of two dual carriageways produces four > intersections and makes the turns much sharper than in reality. > > My use case isn't the only one that has issues with this sort of thing; > routers can "see" more traffic lights than actually exist and can (so I > hear, anyway) give directions that are potentially confusing. > Intersection modeling is a long-standing issue that has had multiple > previous proposals. > > The major two prior proposals of which I'm aware are to map the > 'footprint' of the intersection as an area, or to create relations to > map the intersection. Both are difficult, both to model, and for tools > to parse. The area proposal has potential rendering issues. > > I am proposing² a *much* simpler alternative, which is to simply tag the > portions of a road that are "part of" an intersection (i.e. the 'm', > 'n', 'p', 'q' segments of > https://wiki.openstreetmap.org/wiki/File:Doublejunction.svg) with > junction=intersection. This is straight-forward to model, and I believe > solves most of the issues for a majority of affected intersections. > (Exceptions likely exist, but 'perfect' is the enemy of 'good', and > right now we're at 'bad'.) > > Comments would be appreciated! > > Also, should I start just doing this for the areas I'm trying to use for > my project, or is it better to wait for some degree of consensus? > > (¹ https://www.eclipse.org/sumo/) > > (² > > https://wiki.openstreetmap.org/wiki/Proposed_features/junction%3Dintersection > ) > > -- > Matthew > > ___ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging > ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
[Tagging] Feature Proposal - RFC - junction=intersection
As some of you may recall, I'm working on a project to do traffic simulation with the help of OSM data and SUMO¹. One of the issues that SUMO has is that the typical method of modeling intersections (which I don't propose to change, mostly) results in SUMO thinking there are multiple intersections where there should only be one. For example, intersections of two dual carriageways produces four intersections and makes the turns much sharper than in reality. My use case isn't the only one that has issues with this sort of thing; routers can "see" more traffic lights than actually exist and can (so I hear, anyway) give directions that are potentially confusing. Intersection modeling is a long-standing issue that has had multiple previous proposals. The major two prior proposals of which I'm aware are to map the 'footprint' of the intersection as an area, or to create relations to map the intersection. Both are difficult, both to model, and for tools to parse. The area proposal has potential rendering issues. I am proposing² a *much* simpler alternative, which is to simply tag the portions of a road that are "part of" an intersection (i.e. the 'm', 'n', 'p', 'q' segments of https://wiki.openstreetmap.org/wiki/File:Doublejunction.svg) with junction=intersection. This is straight-forward to model, and I believe solves most of the issues for a majority of affected intersections. (Exceptions likely exist, but 'perfect' is the enemy of 'good', and right now we're at 'bad'.) Comments would be appreciated! Also, should I start just doing this for the areas I'm trying to use for my project, or is it better to wait for some degree of consensus? (¹ https://www.eclipse.org/sumo/) (² https://wiki.openstreetmap.org/wiki/Proposed_features/junction%3Dintersection) -- Matthew ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
