Feature Proposal - RFC - junction=intersection

classic Classic list List threaded Threaded
15 messages Options
Reply | Threaded
Open this post in threaded view
|

Feature Proposal - RFC - junction=intersection

Matthew Woehlke
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
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Feature Proposal - RFC - junction=intersection

Peter Elderson
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 <[hidden email]>:
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
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Feature Proposal - RFC - junction=intersection

Matthew Woehlke
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
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Feature Proposal - RFC - junction=intersection

Peter Elderson
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 <[hidden email]>:
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
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Feature Proposal - RFC - junction=intersection

Clifford Snow
In reply to this post by Matthew Woehlke
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 <[hidden email]> 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
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging


--
@osm_washington
OpenStreetMap: Maps with a human touch

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Feature Proposal - RFC - junction=intersection

Matthew Woehlke
In reply to this post by Peter Elderson
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
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Feature Proposal - RFC - junction=intersection

Tod Fitch-2

> On Jul 10, 2020, at 9:26 AM, Matthew Woehlke <[hidden email]> 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



_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Feature Proposal - RFC - junction=intersection

Matthew Woehlke
In reply to this post by Clifford Snow
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
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Feature Proposal - RFC - junction=intersection

Matthew Woehlke
In reply to this post by Tod Fitch-2
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
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Feature Proposal - RFC - junction=intersection

Matthew Woehlke
In reply to this post by Matthew Woehlke
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
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Feature Proposal - RFC - junction=intersection

dieterdreist
In reply to this post by Matthew Woehlke


sent from a phone

> On 10. Jul 2020, at 16:17, Matthew Woehlke <[hidden email]> 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
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Feature Proposal - RFC - junction=intersection

Matthew Woehlke
On 10/07/2020 15.01, Martin Koppenhoefer wrote:

>> On 10. Jul 2020, at 16:17, Matthew Woehlke <[hidden email]> 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
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Feature Proposal - RFC - junction=intersection

Jarek Piórkowski
On Fri, 10 Jul 2020 at 15:53, Matthew Woehlke <[hidden email]> wrote:

> On 10/07/2020 15.01, Martin Koppenhoefer wrote:
> >> On 10. Jul 2020, at 16:17, Matthew Woehlke <[hidden email]> 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
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Feature Proposal - RFC - junction=intersection

dieterdreist
In reply to this post by Matthew Woehlke


sent from a phone

> On 10. Jul 2020, at 21:52, Matthew Woehlke <[hidden email]> 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
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Feature Proposal - RFC - junction=intersection

Matthew Woehlke
In reply to this post by Jarek Piórkowski
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
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging