My work area (Visalia, California) has been worked on by TeleNav mappers modifying intersections between dual carriageways and cross streets whose carriageways merge at the intersection, and they now have the characteristic “pencil tip” style recommended in the second main section of Intersection Modeling | Mapbox. I have several issues with this mapping style:
It’s visually unattractive. (Subjective, I know.)
It misleadingly suggests the dual carriageway continues beyond the cross street.
It makes a mess of turn restrictions.
Adding traffic signals (which ideally go before the intersection on dual carriageways IMO) or crosswalks is nearly impossible on the pencil tip side.
As executed in Visalia, higher-level classifications which should end at the cross street extend through the pencil tip, which seems completely wrong.
It’s inconsistent with Mapbox’s own third recommendation for Y-shaped intersections on the above linked page, which explicitly discourages pencil tips.
I know it’s apparently better for routing, but it’s bad data IMHO. This seems like “tagging for the router”, and perhaps the routers need to adjust to the data rather than the other way around? That also leaves the question of what the “correct” way of drawing these intersections should be.
Extended pencil tip is outright wrong, it maps fake nonexisting carriageways.
It is an unwanted invalid incorrect mapping for router.
This is a good reason to consider this entire Mapbox tagging reccommendations as deeply suspect and something that should not be recommended to anyone.
Mapbox should fix this invalid recommedation and fix all crossings damaged by such mapping of their employees.
When describing the issues with a tagging method collaboratively, let’s stick to facts only. No need to dilute it with subjective or unrelated things like point 1 and point 6. The end goal should be to document the pros and cons of each method in the wiki to give a recommendation. Hence, any argument given should be accompanied by an explanation.
My opinion about “tagging for the router”/“tagging for the renderer”/…
I think the duty of the mappers is to provide enough factual information for the data consumer to use.
The (developer of the) data consumer should then properly interpret that data to provide it’s function.
Modifications of the map should be based on reality, not just to aid a data consumer in interpreting the data.
With regard to the MapBox suggestions. The only benefit they seem to mention is that it will give better turn announcements. We want one turn announcement per junction, but we don’t describe what belongs to the junction. Instead, the navigation software is supposed to guess which nodes belong to the same junction.
So whatever the “correct” way to map these junctions is, I would argue that an area:highway=junction should be present on these complex junctions. Navigation software could then look at the roads coming out of the junction area and their direction to determine the right announcement. This frees up the roads within the intersection to best represent road geometry and/or turn restrictions.
Note: I found one of the junctions in the pictures (OpenStreetMap). It has been changed to what seems to me a better solution than mapbox suggests because it does not have road parts that don’t exist in the real world.
In regards to explanation. I myself have no idea which is better or not, so I will just prompt you (or those who know) to explain each point in pro/contra. After all, the goal is to find a clear overview why one tagging should be preferred over another and that overview must be cogent:
Re: Contra pencil tip past intersection
It misleadingly suggests the dual carriageway continues beyond the cross street.
Why is this is a problem?
You could say that the other method misleadingly suggests that the road does a bend
It makes a mess of turn restrictions.
Please explain. (Best with an illustration.) For the vanilla examples above, assuming there are no special restrictions, the intersection works just fine without any such relation. The steep angles for the “pencil tip ends at intersection” are not possibly a problem?
Adding traffic signals […] or crosswalks is nearly impossible on the pencil tip side.
Could you illustrate? I don’t understand the issue.
As executed in Visalia, higher-level classifications which should end at the cross street extend through the pencil tip, which seems completely wrong.
Why would this be a problem?
If this is a problem, could it not be fixed by (in this example) re-classifying it like this?
Extended pencil tip is outright wrong, it maps fake nonexisting carriageways.
Any road on the area of an intersection is fake/virtual. You could say the same about the bent roads in the “pencil tip ends at intersection” example.
Because I’m quite new with osm mapping, I have been/is uncertain how to map these things.
One “rule” is: separate osm ways if in real lanes/roads are physical separated, but in an intersection normally this is not the case. As a car driver you can travel almost in any direction when in the intersection, even if it’s against the law.
Is the point of how lanes/ways are drawn only (?) matter of how current routers interpret the osm data?
Then the router can elide the turns into a general “turn left at the intersection” rather than generating fake “slight left / fork right / etc.” instructions.
I’m not aware of any routers that do this yet (but I’m very tempted to implement it for cycle.travel).
It misleadingly suggests the dual carriageway continues beyond the cross street.
Why is this is a problem?
Because it doesn’t match the ground truth, plain and simple. The dual carriageway physically ends before the cross street, and logically ends at the cross street. Neither is after the cross street.
It makes a mess of turn restrictions.
Please explain. […]
I’ll tag @Minh_Nguyen on this one, since he originally brought up that point on the original OSMUS Slack discussion. I don’t do much turn restriction tagging myself in general.
Adding traffic signals […] or crosswalks is nearly impossible on the pencil tip side.
Could you illustrate? […]
East Houston and North McAuliff on the other side of Visalia (OpenStreetMap) is a good example where I left the pencil tip in and added the signals and crosswalks. Note that the pencil tip had to be extended beyond the bounds of the intersection, which is a flat-out lie.
As executed in Visalia, higher-level classifications which should end at the cross street extend through the pencil tip, which seems completely wrong.
Why would this be a problem?
Having a short stub like that as part of a higher-level road network is bad for network continuity.
If this is a problem, could it not be fixed by (in this example) re-classifying it like this?
In this specific example, yes, but what if the road changes names or designations at the intersection? Either the new road wouldn’t start at the cross street (bad in general), or the new road would start with a dual carriageway segment that doesn’t exist (bad modeling).
How is it better for routing?
We’ve already established that Mapbox found them to be better for turn announcements. Does that not fall under the umbrella of routing?
If I saw a “pencil tip” junction mapped like that, I would assume that there are median islands in the road that extend that far. This would then require a different crossing configuration. While what goes on in a junction isn’t a “real” shape, it is usually an abstraction bases on its actual geometry. The named roads and the physical separators do have specific endpoints that can be reflected in the junction configuration, and omitting them just seems like prioritizing one specific use case.
Hi everyone, thanks for weighing in on this guide, especially for trying to articulate the practical pros and cons of the recommended approach. I’ve forwarded the feedback in this thread to Mapbox’s mapping team, along with some of my own observations, in order to consider whether the guide’s recommendations need to be updated.
The practice of extending a “pencil tip” outside of the intersection isn’t limited to Mapbox or this guide by any means. In fact, I took Telenav to task over the practice way back in 2013. (There was some initial confusion in the thread, but I think it ended up with a consensus to keep the pencil tip inside the intersection.)
When my colleagues at Mapbox later wrote this guide, both the internal and external pencil tips were common mapping styles in the database, at least in the U.S., but the wiki was conspicuously silent on the issue. (It only talked about intersections between two dual carriageways.) The team ended up picking one of the approaches in an effort to highlight straightforward best practices for people learning how to map. The mapbox/mapping repository accepts pull requests because it’s intended to reflect current trends with input from the community, rather than imposing a novel approach on OSM from outside.
If there’s a no U-turn restriction at one of these intersections, at least two turn restriction relations need to be present to enforce it. A realistic turn restriction would be applied to the intersection, with one more via way than otherwise needed, and an artificial (implied) turn restriction would be applied to the pencil tip.
Spot-checking up and down California, I’ve seen that virtually every intersection mapped with an external pencil tip that has a no U-turn restriction was missing one or the other turn restriction relation, regardless of which mapper or mapping team redrew the intersection. That causes the router to do a donut to violate the restriction. For example, OSRM and Valhalla both dance around this restriction while GraphHopper lacks support for its via way.
By itself, these mistakes don’t make external pencil tips the wrong approach. After all, some intersection designs require lots of turn restriction relations, no way around that. But I offered it as a word of caution for anyone considering that approach.
Incidentally, I was wracking my brain last night on how to find intersections mapped in either style. I wound up querying Overpass for turn restriction relations last edited by certain users and manually inspecting the results. Does anyone have any suggestions on how to find these intersections more efficiently?
Thanks for the pointer about junction areas. Routers like OSRM and Valhalla can already smooth out artificial turn angles and collapse complex intersections based on a variety of heuristics, but a more data-driven approach might be appealing to these projects. Once there’s a critical mass of coverage and some editor support, it’ll be easier for these routers to justify adding support for them too, but it couldn’t hurt to file a feature request in their bug trackers. (Currently there’s an open issue for OSRM to consider junction area names in guidance instructions but not for intersection detection.)
OSRM also supports maneuver override relations, which can solve this problem very easily. However, that relation type is supposed to be a last resort for very troublesome, very rare edge cases, rather than these standard intersections.
I don’t know the situation in the US but around here I have never seen this mapping style suggesting carriageway separation specifically and purposefully on intersections where there isn’t. The wiki has always been very clear: only separate the highway directions if there is a separation of the carriageway. The wiki was not silent, simply it didn’t comment on this kind of “mapping for routing instructions”-style, hence it is discouraged/“wrong” as is any similar ignoring of general mapping rules Tagging for the renderer - OpenStreetMap Wiki
wiki is incapable of documenting every single wrong type of mapping as wrong, but it was clearly documenting that highway=* road lines represent separate carriageways.
Only some of extremely common types of bad mapping get explicit documentation “this is wrong”.
At least I am far more likely to contribute to OSM Wiki than do unpaid work on internal Mapbox documentation.
The strongest correlates of pencil tip intersections locally are probably ways with a high classification and no maxspeed tag, or conflicting lane counts and turn lane tags. I was able to find some with these overpass queries anyway, it probably varies depending on people’s mapping habits
I see a confusion in the discussion as there are several moments that also have to be clarified: road definition, directions of movement, deviations from the direction of movement and definition of an intersection.
Take a look at the screenshot where clearly visible tracks of the cars, how they cross the intersection. Answer the question whether these tracks coincides with the drawn road geometry? How does the geometry of the tracks change when they cross an intersection without changing the direction of movement and when they make a turn?
An intersection is a junction or an area of the roadway where two or more roads cross or meet. An intersection can be four-way (or crossroads), three way (T-junction or Y-junction, sometimes refer to as a fork), or five or more ways. (https://www.driverseducationusa.com/resources/what-is-an-intersection/)
It is also worth noting that at the intersection there is a change in the direction of movement of vehicles - this is their main function - to allow turns from one road to another.
Thus, the intersection is not a point, but a place with a certain area as @spaanse mentioned above.
In my screenshot you can count the collision points between the traffic directions, more than one of them, but none in the central part, where the point of the intersection itself is now.
For the first, quick, data filling, this method of mapping is minimally sufficient, if you only need a grid of roads. But if you’re aiming to provide as much information as possible to data consumers, you need to think about it more thoroughly.
How will the car’s autopilot process this data? How to switch from a simplified view of the intersection to a full one?
Someone’s life will depend on the correctness and completeness of this data.
I am very happy to see this discussion. I hope that it will lead to an improvement in the quality of intersection data in OSM.
PS Think about that moment in time when we will map (have) not only a grid of roads in the form of lines, but also polygons of roads for their accurate visualization and navigation.
By way of an update, Mapbox’s mapping guides have been taken offline. However, the source code is still available on GitHub under a CC0 public domain dedication, in case anyone wants to crib from it while editing the wiki.
