OpenStreetMap 로고 OpenStreetMap

Do not map like this (a collection of incorrect mapping practices)

DUGA님이 English로 2021년 10월 14일에 게시함. 최근 2021년 10월 25일에 업데이트됨.

This entry will be constantly updated based on my findings in USA.

Please be advised that a correct solution depicted below is not the only one. You are welcome to brainstorm in the comment section!

Hint: Right click on the picture to view in a new tab so you will see it in a better size.

1:

Wrong:

The reason why the intersection originally looks like this is to prevent reckless driving in rural area.

Correct:

or

or

If you don’t want to hear the awful sound coming from TTS saying “Turn right and then turn left” to “Continue”, then map like this.


2:

Wrong:


3:

Wrong:

Correct:

I did not address the sidewalk issue here because I always drive. My understanding is: if drawing road/sidewalk as a line instead of an area, there is no need to cut the crosswalk to make it “detailed”, because the part you cut as sidewalk is already a part of the crosswalk. Theoretically they are like this (crosswalk in orange):

Connecting a crosswalk to a sidewalk, is to ensure a routing is possible, but nothing related to accuracy (if you don’t have a survey-grade GPS, don’t try to tell me your mapping is accurate). If you wish to differentiate the tiny area(s), using curbs on the junction node instead:


4:

Wrong:

Correct:


5:

Wrong:

Correct:


6:

Wrong:

Correct:


7:

Wrong:

Correct:


8:

Wrong:

Correct:


9:

Wrong:


10:

Wrong:

Correct:

이메일 아이콘 Bluesky 아이콘 Facebook 아이콘 LinkedIn 아이콘 마스토돈 아이콘 텔레그램 아이콘 X 아이콘

토론

2021년 10월 15일 13:30H@mlet님의 의견

Well, I understand for the second one, but the other two look pretty accurate to me.

Would you care to explain and source your reasoning?

Regards.

2021년 10월 15일 13:53DUGA님의 의견

“Accurate”?

Maybe you should turn right and turn left to go straight, but I won’t!

2021년 10월 15일 14:31pkoby님의 의견

1: That’s how I’d do it (maybe a little better aligned). 2: I’d move that 90 degree node north, but I would keep it a bit angled. 3: If you’re talking the Tewkesbury to the driveway zigzag, I’d move Tewkesbury more north, farther from the driveway. If you’re mentioning the truncated sidewalks, then yeah, silly.

But maybe this post would be easier if we didn’t have to guess…

2021년 10월 15일 17:00DUGA님의 의견

Good point, I will provide some hints in the future.

2021년 10월 15일 17:21DUGA님의 의견

Added. @pkoby thank you for the suggestion!

2021년 10월 15일 17:29pkoby님의 의견

Good addition!

That said, I strongly disagree with your 1 and 3 mappings. I can understand your rationale for #1, but essentially you’re “mapping for the router”, if you will. Perhaps if you realign the roads to match the centerlines with a curve at the intersection, I could get on board, but you’ve misaligned the road line from the imagery. Given your recent posts on Slack about how important aligning buildings properly is, this seems a bit strange.

For #3, why should a residential road (I think) have to connect directly to a private driveway? Why can there not be a zigzag there? Almost no one will be using a GPS to drive from Tewkesbury into a driveway, and if they are, it’s probably not a big deal if it’s telling you some strange directions. And the imagery shows that they clearly don’t hit the main road in the same spot.

2021년 10월 15일 21:07DUGA님의 의견

@pkoby. Not specifically mapping for router.

Currently roads are mapped as lines but not area. As long as you draw the line within the road area (which is not a widely-adopted idea), it is fine. There is no strict rule saying that mapper must follow centerline, and in fact not following centerline sometimes can make the entire road look better (I’m also not tagging for the renderer).

What is considered as mapping for router, is something like this below, using a very unobtrusive sharp turn to “overlap” with the other road:

Imgur

2021년 10월 15일 21:28RobJN님의 의견

In example 1: how much further apart should the roads be before you don’t join them? It’s not always easy to know!

Instead of “Turn right and then turn left” routers could say “go over the staggered crossroads” or something similar.

2021년 10월 15일 21:49DUGA님의 의견

@RobJN It currently looks like this.

I have to admit that I was lazy on this. In fact, I usually add 2 nodes for the stop signs, cutting straightening two segments both from stop signs to the intersection like this (I added this into the diary as another correct solution):

For #1:

The blue box is the nearest property with entrance on the residential street, so it is better not to have the “deviated” road line north of the entrance.

The white box is the south side of the secondary road, no property built, only a short service road. so you can cut the segment from the service road, but in this example it is much longer than needed. I just cut the segment at stop sign and straighten:

  1. A segment between the intersection node and the property entrance
  2. A segment between stop sign and the intersection node

to ensure that the “deviated” road line is still within the road area.

2021년 10월 16일 02:50pkoby님의 의견

I wouldn’t say it’s a hard and fast rule to follow the center line, but let’s be honest and admit that pretty much matching the middle of the road makes sense. Otherwise, the map is simply not accurate. I get that it’s not the most important thing to have roads aligned exactly to the centimeter, but I think it’s a slippery slope to start suggesting that somewhere within the road area is good enough.

To clarify, I don’t think mapping the double-yellow line is necessary, and often does make things look wrong. Or when a turn lane on one side of a dual carriageway juts out, I don’t think you should shift the road to the middle of all those lanes. But can we agree that you should try to match the shape of the road as centered as possible in most cases?

I do agree with your extended mapping of #1 from the stop lines; I do that frequently myself.

2021년 10월 16일 03:38DUGA님의 의견

I follow centerline when the lane number is even except for few examples like above. When the number is odd, the situation becomes complex and mapping varies.

Routers will consume the road line data and stick their users to the nearest routable segment if possible. That’s why I mentioned before, it is totally acceptable to map the line within the area. Of course, I did not endorse that people should draw whatever they like as long as it is within the road area. Instead, a flexible mapping practice is preferred when tricky things are right there.

2021년 10월 16일 11:31RobJN님의 의견

@DUGA: I agree with you on number 1. My point was that it can be down to individual opinion. For example if the road was an extra 1m, 2m, or 5m offset, would you still join them…? (Not an actual question I want answering, just making the point that it isn’t always clear)

2021년 10월 16일 14:35DUGA님의 의견

@RobJN Definitely not always, but I cannot give you an exact number regarding offset. 1m or 2m could be acceptable. 5m may look worse so I wouldn’t do unless the routing is damaged.

2021년 10월 16일 19:04Richard님의 의견

If you don’t want to hear the awful sound coming from TTS saying “Turn right and then turn left” to “Continue”, then map like this.

I agree (and indeed I do generally map like that), but a halfway competent router will collapse the turn instructions in this case. For example: https://cycle.travel/map?from=&to=&fromLL=51.895321,-1.406647&toLL=51.896255,-1.405649

2021년 10월 16일 22:17RobJN님의 의견

Nice example Richard (and much nicer wording in the router than my suggestion above). This is one example which is just those extra few meters apart that it is not right to connect the roads. What I’d call a classic staggered crossroad. No idea how common they are outside the UK though.

2021년 10월 24일 11:55user_5589님의 의견

You’re wrong with your first example.

It is not a crossroads, it’s a staggered junction. Therefore it should be mapped as a staggered junction and not a crossroads.

You’re also wrong with your third example.

Again the two things are offset, indeed they are offset considerably more than in the first example. Also as others have pointed out, why does a private drive have to be in a crossroads with a public highway?

There’s also a major faux pas in the tenth example as well. The “correct” version adds what appears to be a parking aisle to the setup. The geometry of the oblique side road is correct in the second version, but the geometry of the parking aisle is an absolute abomination. It goes straight through parking spaces. If you’re going to add detail like a parking aisle or service road then it should be added such that its geometry is correct, just as the geometry of the oblique side road should be correct and was adjusted to be correct.

2021년 10월 24일 12:23Marc Mongenet님의 의견

What is wrong with #1-wrong is that the yellow road is not mapped with a perfectly straight line. #1-correct-1 and #1-correct-2 are both wrong, and I always fix such errors on staggered junctions. On #3-wrong the centering is poor and should be fixed. #3-correct is just awful, only acceptable for a first draft made with poor quality photography, or a beginner with iD. #4 is a difficult case. I always hesitate with such cases. #5 to #9 I fully agree.

2021년 10월 24일 12:45DUGA님의 의견

This is USA. A staggered junction does not mean you have to map in that dumb way. Adding stop signs will properly solve the issue. Just like highway gantries, people should not spend time mapping gantries, instead they should put exit information on ramps directly. The junction forces people to slow down and stop, but not making you drive in an undesirable way. Any router should not try to be smart by collapsing that tiny segment as it is a rash behavior.

I did not mention routing penalty because I’m not mapping for router. However, this is also one of the possible factors that OSM based routers giving you a longer than usual time consumption because of that tiny segment on the secondary road if not handled carefully.

Again, if you hear anything asking you to turn right and then turn left but you are supposed to stop and go straigtforward, it always mean the mapping is wrong.

For the 10th example, adding a parking area for the entire lot will easily solve the issue. What I added is a service road (not wrong though). A parking aisle could be added from the node in the middle towards the red light ending at the verge of the lot.

2021년 10월 24일 12:53DUGA님의 의견

Sorry Marc, I was reply to the user above you before refreshing the page on the phone.

Thank you for reading and sharing your idea, I will definitely try my best to improve it.

2021년 10월 24일 14:03user_5589님의 의견

“This is USA.”

And …? What relevance does that have to the situation? A staggered junction is a staggered junction is a staggered junction. It doesn’t matter where in the world it is. What matters is that it is a staggered junction. As a corollary what then matters is that the staggered junction is mapped correctly. Mapping it is a conventional crossroads is by definition not correct.

“Again, if you hear anything asking you to turn right and then turn left but you are supposed to stop and go straigtforward (sic), it always mean the mapping is wrong.”

Yes. Except you ARE supposed to turn right and then turn left. That’s why it’s called a staggered junction. I’d definitely agree with others that it’s the routers that are wrong in that case. They should treat it as a staggered junction, not as two completely separate junctions. Tagging could perhaps help with this by marking it as a staggered junction, but that’s tricky as it’s somewhat subjective as to the exact border line. However in case one it’s a staggered junction, and in case three the service road has nothing to do with the main junction, it just happens to be near it.

Now for those who want to look at this on Google Streetview, example one is the junction of West Trimble Road, Old Stonehouse Road North and Old Stonehouse Road South in between Carlisle and Mechanicsburg Pennsylvania. It’s not a particularly large stagger for the junction, but it’s definitely there. For comparison purposes look at the junction between West Trimble Road and South Middlesex Road a little further to the west. Now THAT really is a crossroads. Roads either side of the junction on the same alignment with no stagger at all.

What really strikes me on the Streetview images is just how awful the positioning of the stop lines at those junctions. In both cases the stop lines (where they’re actually painted on the road) are far, far too far back from the edge of West Trimble Road. Stopping at those stop lines gives no proper view of the junction from the north in both cases. A house in one cases and two lines of trees in one case utterly obstruct the view of the main carriageway at the stop line.

Now that really is the USA. That epitomises a significant part of the reason why the US has such unsafe roads: dreadful highway design. There’s the over-use of stop signs, and the unsafe location of the stop signs when they’re used. Two cardinal sins of US highway design. See that’s something where it really does matter that this is the US, unlike mapping staggered junctions as a concept which is geographically agnostic.

2021년 10월 24일 15:11DUGA님의 의견

We (yes I used to work nearby) don’t drive like you mentioned above. That’s it, and we don’t care. If you checked Google Streetview, I seriously doubt how you still think that “Except you ARE supposed to turn right and then turn left”. No, we are not supposed to do that at that place.

You may write to PennDOT to explain your concern. I will stop replying here because we definitely have no chance to reach concensus. As a local mapper of Pennsylvania, I’m jaded of replying to this anymore.

PennDOT Customer care: https://customercare.penndot.gov/

PennDOT Traffic Volume data: https://www.penndot.gov/ProjectAndPrograms/Planning/Maps/Pages/Traffic-Volume.aspx

2021년 10월 24일 19:01Carnildo님의 의견

#1 might not legally be a turn, but if I were driving that road at night, I’d sure want my GPS to say something to explain why I’m seeing oncoming headlights to my right.

2021년 10월 24일 21:19Minh Nguyen님의 의견

a halfway competent router will collapse the turn instructions in this case.

Exactly, routers can collapse staggered intersections for the purpose of guidance instructions. The threshold for collapsing an intersection may not be perfect, but ideally it would depend on the mode of transportation, because a pedestrian and a motorist would naturally disagree about whether an intersection of a certain size is staggered or not.

Moreover, a router might need to give an affirmative “continue straight ahead” instruction, rather than staying silent as it would for a better aligned intersection. For example, the turn lane signs and road markings at this intersection point straight ahead, but if you’re behind the wheel with barely a line of sight to the other side and hear nothing from the application, you might wonder whether you’ve missed a turn or the application is buggy. This intersection even has a fanciful turn lane diagram to tell motorists to swerve right then left. (I’ve been collecting sign examples on the wiki.)

These nuances get lost if mappers go out of their way to contort roads to line up at these intersections. That said, it’s a matter of degree: at a small enough offset, staggering the intersection in the database would be pedantic even from a pedestrian’s point of view. I’ve searched traffic engineering papers for answers about where to draw the line, so to speak, but I haven’t found anything that conclusively addresses this question. Apparently 50 meters (164½ feet) is widely considered the minimum distance for two distinct T-intersections (China, UK), but there’s plenty of gray area within that distance.

The TIGER import gets an honorable mention here because it represented staggered intersections in the worst possible way: as a tiny, unnamed residential way connecting the two phases of the intersection, interrupting the continuous street. Many of these ways remain undertagged in OSM all these years later because they’re so hard to spot. Here’s a crude example Overpass query for this and similar issues across Indiana.

2021년 10월 25일 00:16MxxCon님의 의견

You “7 correct” is looks incorrect. Right turning turning slip lane starts way earlier. If you didn’t notice that, delete your account immediately.

2021년 10월 25일 00:26Minh Nguyen님의 의견

You “7 correct” is looks incorrect. Right turning turning slip lane starts way earlier.

Can’t tell if you’re being ironic, but just in case: that slip lane as mapped begins close to where the physical separation begins. The lane may begin way earlier, but that’s why these ways have turn:lanes:forward and change:lanes:forward tags. Otherwise, the whole intersection would be a mess of left-turning link roads.

2021년 10월 25일 00:55MxxCon님의 의견

And yet, turn restrictions look like this.. Incorrect turn restritions Looks pretty wrong to me. Most of those segments not supposed to have U-turns, nor left across solid yellow.

2021년 10월 25일 01:29Minh Nguyen님의 의견

Most of those segments not supposed to have U-turns, nor left across solid yellow.

Different local communities have very different, sometimes very strong preferences as to whether implicit U-turn restrictions should be mapped using relations. In this case in Ohio, you probably won’t get told off for adding them, but it’s also not a high priority because routers are very unlikely to suggest unlawfully pulling a Uey. (Also, most if not all OSM-based routers only suggest U-turns along divided roads, aka dual carriageways, because of uncertainty about OSM’s coverage of U-turn restrictions. Chicken, meet egg.)

Turning left at all these points is technically legal. Ohio’s relevant laws are lax compared to some other states like New York when it comes to double-yellow lines. But the gas station entrance is clearly shaped to discourage left turns, so a turn restriction there wouldn’t be unreasonable.

2021년 10월 25일 01:33MxxCon님의 의견

Ah, see, local particularities matter and one answer doesn’t fit all possible situations, considering calls to delete ones’ account if it doesn’t match how THIS mapper sees things.

2021년 10월 25일 01:38MxxCon님의 의견

Somebody who has > If your changeset gets a comment from me, you did something either wrong or incorrect. and > I do not accept any challenges in these regions regarding my edit’s verifiability.

in their OSM profile better have their edits absolutely perfect and immaculate. Otherwise, they should delete their account immediately.

2021년 10월 25일 03:57Kovoschiz님의 의견

That’s a long discussion for a diary. I will simply mention one of my recent observations on angled intersection geometry: Make a right-angle by considering a perpendicular line normal to the give-way / stop / signal line (as a tangent).

2021년 10월 25일 04:01DUGA님의 의견

@MxxCon I assume that you are not trying to start a debate here, right? By judging other’s profile does not help you capture a moral high ground here. Also, my example #7 is purely on turn restrictions, if you find something else, go ahead and fix by yourself. Your reply posted all turn restrictions of that area, that does not relate to #7.

I don’t leave comments in NYC. I only leave comments of where I map. Enjoy your life.

2021년 10월 25일 04:12MxxCon님의 의견

What is there to debate if you straight up say that you will not accept any challenges where you edit? You edits must be perfect and immaculate. There’s 0 possibility of any errors or mistakes in them. 👼

Yes, your example #7 is purely on turn restrictions, yet turn restrictions on that intersection are wrong…oops.. But you will not accept any challenges on the fact that they are wrong, so 🤷‍♂️.

I didn’t forbid nor ask you to leave comments in NYC. What does that have to do with anything?

2021년 10월 25일 04:51DUGA님의 의견

What is wrong with #7? I highlighted the node, pointing out that you should not turn left as well as drive across the white line, from gas station to the ramp.

You were expecting me to fix everything in that area and keep everything correct. You should ask the guy who imported TIGER to do that. I always manage to make everything correct, but that’s an at will thing.

Yes, I don’t accept challenges of my edits. I must ensure that all my edits are valid. Then you are trying to challenge me with an area mixed of edits from all other people and blame me again.

You already failed with the attempt on U-Turn, what is your next target for the puns here?

2021년 10월 25일 05:00MxxCon님의 의견

What is wrong with #7? To quote your own words: If you cannot find the obvious mistake here, delete your account immediately.

2021년 10월 25일 05:12DUGA님의 의견

Then there is nothing wrong.

Thanks for reading my post!

2021년 10월 25일 11:46pkoby님의 의견

@DUGA: You’re not perfect, and you do accept challenges to your edits: osm.org/changeset/112188491

We all make mistakes. Some ways we map will differ from the ways of others, and they may both be valid. OSM has an interesting way of becoming very personal, and someone mapping differently can feel like an attack, but to everyone: your method could be wrong.

Can we all step back, try to cut everyone some slack, and assume the best intentions? Let’s not recommend deleting accounts over opinions.

2021년 10월 25일 13:35DUGA님의 의견

@pkoby I’m definitely open to change, your first comment came at Oct 16 when I accepted the idea by putting a “correct” sample for each case above.

2021년 10월 25일 15:55Mateusz Konieczny님의 의견

if you don’t have a survey-grade GPS, don’t try to tell me your mapping is accurate

I don’t use survey-grade GPS for mapping and my mapping is accurate.

2021년 10월 25일 15:57Mateusz Konieczny님의 의견

And in the 10th example your “improvement” is both

  • not really correct
  • ironically likely to produce bad instructions in voice navigation

2021년 10월 25일 16:48DUGA님의 의견

@Mateusz Konieczny You are welcome to post an image to show your solution so I can take a better look.

For TTS, I’d say a manual change is needed. However, that’s not supported in OSM right now (is that right?).

2021년 10월 25일 21:37Minh Nguyen님의 의견

It looks like example 10 is intended to point out that the parking lot entrance should connect to Berryhill Street despite Berryhill approaching Derry Street at a sharp angle. It does require introducing a bit of a kink in Berryhill, which could cause an unsophisticated router to announce a standard right turn from Derry onto Berryhill rather than a sharp turn, based on a literal calculation of the turning angle. Fortunately, a half-decent router would classify the turn more holistically, by calculating the angle based on a point along Berryhill farther away from the intersection (great diagrams in that issue). So it would still be a sharp right turn. If it didn’t do that, the router would incorrectly classify all sorts of intersections in OSM, like this ostensible sharp right turn from Fox Street to Walnut Street.

2021년 10월 26일 07:24Mateusz Konieczny님의 의견

I tried to preserve

  • topology (which is useful as you point out, though rhetoric is a bit extreme)
  • road shape
  • intersection shape

At cost of deviating from strict centerline matching (what is often done, for good reasons)

osm.org/edit?editor=id#map=21/40.26140/-76.85723

alt text

PS is access=destination an actual legal restriction there?

2021년 10월 26일 07:25Mateusz Konieczny님의 의견

I also fixed shape of road on parking, added parking itself (with access=unknown, feel free to detail it if you are familiar with this location), added missing parking aisle.

2021년 10월 26일 12:53DUGA님의 의견

I would still straighten Derry St because it looks better and it should be that way. Derry St has much higher functional classification and should not be compromised. The angle should be okay still after that.

The parcel owner has the rights to say no thru traffic when the road is also owned as private. So no problem doing that.

The parking aisle is correctly mapped (I would just draw as a straight line but it does not matter in this case). access=customers should be used. No free parking there (yes you will be towed).

Regarding 2 chains, I’ve not been there in the evening. If these will bring negative impacts to routing during the day (since they are barriers), I’d remove them. Of course, if the owner decides to block road after business hours, it can be added with a conditional restriction, but I have no clue on that and I can’t verify them.

2021년 10월 26일 20:57Minh Nguyen님의 의견

I added the chains on either end based on Bing Streetside imagery, which was taken during the day: the northern entrance was roped off, while the southern entrance was not (just the posts were visible). Only the northern one was tagged access=private, preventing the parking lot from being used as a cut-through. This old imagery isn’t contradicted by newer aerial imagery. If I’m not mistaken, barrier=chain is assumed to be passable unless otherwise specified (just like barrier=gate). Some barrier values may have implied access restrictions, like block, but explicit access tags are a good idea to avoid surprises.

2021년 10월 27일 11:13Mateusz Konieczny님의 의견

I would still straighten Derry St because it looks better and it should be that way. Derry St has much higher functional classification and should not be compromised. The angle should be okay still after that.

Oh right, it ended being moved a bit. I straightened it now.

The parcel owner has the rights to say no thru traffic when the road is also owned as private. So no problem doing that.

The problem is whether this restriction is actually applied (some people map nonexisting restrictions and I worried that may happen here)

access=customers should be used. No free parking there (yes you will be towed).

Done!

댓글을 남기려면 로그인하세요