Pedestrian crossings on boulevards rotated wrong

[dmitriy-serdyuk]

I am trying to import a borough of Montreal currently. It looks like there is a bug for pedestrian crossings on boulevards:

The crossing seems to be rotated 90 degrees. There should be a zebra top right and bottom left and no zebras in the middle.

[dabreegster]

There are a few things going wrong here. First is related to how sidewalks are mapped in OpenStreetMap -- sometimes as separate ways, sometimes as an attribute of the road (sidewalk=left, right, or both), and often not at all. The A/B Street importer uses the attributes when present and makes guesses based on road type when missing. If this area has separate sidewalks and crossings explicitly mapped, then ideally we would import them.

But even with the current approach of placing a sidewalk on the left/right/both sides of each road segment, the way crosswalks are inferred is very unrealistic. If you imagine rotating either direction around the center of an intersection, every pair of adjacent sidewalks (not counting the ones sharing the same corner) get a crosswalk between them. In situations with split one-way roads like this, this heuristic is quite wrong. So I think dedicating this issue to improving that makes sense.

The final issue is mostly cosmetic, although it can incorrectly cause some vehicle turns to look like they conflict with the crosswalk. The crosswalk geometry is always a straight line between the two sidewalk endpoints. Really it should trace along the shape of the intersection and look more like this:

All of these problems have existed for a while because I haven't found a straightforward way to fix them. https://github.com/dabreegster/abstreet/blob/master/map_model/src/make/walking_turns.rs is the one place that figures out which sidewalks should be connected with a crosswalk, and calculates their exact geometry. There's a disabled v2 method in there that tries to simplify things, but it needs more work and doesn't solve all of the problems. If you have any ideas about how to improve the heuristics for where crosswalks go, I'm all ears!

[dmitriy-serdyuk]

You are right. Indeed, the sidewalks are not tagged on OSM. Here is this intersection. Nevertheless, the importer did a good job inferring both sidewalks on the East-West street and only outside sidewalks on the North-South street.

I would imagine that having an intersection like

 S|X
S | S
--┼--
S | S
 S|X

, where S is a sidewalk and X no sidewalk. The crosswalks should be produced connecting only sidewalks with the corresponding direction like

 S|X
S╬══S
-║  -
S╬══S
 S|X

[dabreegster]

I could see that working!

I revived the old attempt at simplifying crosswalk generation. Other importing steps have become more complicated since I wrote it -- in some cases, the importer will try to merge intersections like the one in your first post. It comes out like this:

The crosswalk geometry looks bad, but the connections are reasonable.

Until it's possible to do the intersection consolidation everywhere and get good results, what I'll attempt is to use the existing crosswalk generation, but make a second pass and filter out the crossings over the short road in the middle of the two intersections. In reality, this is likely one large intersection, without much room to stop in the middle. Having people cross in the middle is very unrealistic.

[dmitriy-serdyuk]

And, by the way. I am not sure if you are aware of this (I can create a separate issue).

An alley connected to a road should not allow thru traffic nor produce pedestrian crossings:

I understand that this is not mapped, but it is possible to infer from the tags highway=service, service=alley.

[dabreegster]

I'm not sure I understand the alley problem. No through traffic for anyone? At least with alleys I'm familiar with, there are no legal restrictions preventing a vehicle, cyclist, or pedestrian from going through. There are often physical width constraints that make it highly unlikely two vehicles in opposite directions will attempt to go through at the same time. But from the simulation perspective, any movement should be allowed through, but the routing should strongly prefer to not use alleys.

The crosswalk issue is a little different. Pedestrians in A/B Street can only enter the road using crosswalks. It might be reasonable to not generate any crosswalks because of alleys, but then that forces people to walk all the way around the block. There may be some situations where this produces very unrealistically circuitous routes.

It might be time to evaluate divorcing the physical presence of crosswalks in the map model from how pedestrians can cross. There are plenty of situations around the US that I'm familiar with where there isn't a crosswalk on all edges of a 4-way junction, but it's still standard for people to cross, after yielding to traffic. Possibly the distinction we ought to model is who has the right of way -- when there's a physical crosswalk present and ideally mapped in OSM, pedestrians, and otherwise, vehicles on the road.

[dmitriy-serdyuk]

At least with alleys I'm familiar with, there are no legal restrictions preventing a vehicle, cyclist, or pedestrian from going through.

Sorry, my bad. I did the research, and indeed it is allowed. People just prefer not to do this when there is a lot of traffic.

[dabreegster]

I'm testing a change to remove crosswalks and stop signs from these short "roads." If all goes well, should have it pushed within an hour. Initial results:

becomes

into

[michaelkirk]

Nice @dabreegster! Does this affect traffic flow or just rendering?

[dabreegster]

Both. Stop signs on those short segments really do cause a 0.5s pause, which can't be helping our gridlock. And extraneous crosswalks mean worse traffic signal heuristics, and maybe people cutting in front of turning vehicles in an unrealistic way.

[dabreegster]

@dmitriy-serdyuk If you re-import with the latest code, the inner crosswalks from your example should disappear -- er... actually, only if that road happens to be under 2 meters. You could try locally editing is_extremely_short in map_model/src/objects/road.rs if not. I'm not sure how to set this threshold without breaking some places. As part of #114, I'd still like to try automatically merging short roads like this, which is an even bigger cleanup than the previous commit.

[dmitriy-serdyuk]

It doesn't work very well for my case unfortunately... I had to increase the constant up to 20-30 meters to import this particular intersection. It caused many false positive mergings elsewhere.

I want to try the following heuristic. Merge if

1. a road is extremely short (say, <2m)
2. or; a road is short (say, <50m) and its starting and ending nodes belong to ways with the same name

[dabreegster]

I've considered explicitly tagging https://wiki.openstreetmap.org/wiki/Proposed_features/junction%3Dintersection in OSM for cases like this, but coming up with the precise rules for this tag is tricky ("so that things render in A/B Street" is of course not a valid definition there), and it often requires splitting the way.

I've been tagging https://wiki.openstreetmap.org/wiki/Tag:dual_carriageway%3Dyes in places like this -- it has a very clear definition and is a more widely-used tagged. I'll try your second heuristic with the name matching or dual_carriageway=yes on both of them. The second is a bit more precise, but would require lots of tagging.

[dabreegster]

Furthermore, the intersecting ways on either end should be oneway=yes. I have a heuristic for finding dual carriageways that's mostly geometric: https://github.com/dabreegster/abstreet/blob/2837808206d0b445ec6d7c8fd0b2441c85584ea9/parking_mapper/src/mapper.rs#L598

You can run this detector using https://dabreegster.github.io/abstreet/side_projects/parking_mapper.html and changing the dropdown on the right. I use this tool to look for possible dual carriageways and then manually tag them in OSM. The detection has false positives, so it still requires a human touch, but it finds many cases quickly.

[dabreegster]

@dmitriy-serdyuk You could try changing the distance thresholds at https://github.com/dabreegster/abstreet/blob/322fb81a9d9cb43392c59de8c6cb6dd1291f19df/map_model/src/make/merge_intersections.rs#L64 and just below. The connects_dual_carriageway heuristic has lots of false positives in my tests so far; I'll keep trying to improve it.

Also, if you're at least mildly invested in getting Montreal imported and high-quality in abst, I can start regularly importing and maintaining it. Just send the polygon boundary you're using if so.

[dmitriy-serdyuk]

I was checking OSM for Montreal. It is quite low quality: number of lanes, parking, restricted left turns, u-turns, speed limits. It will take some effort to fix OSM before exporting something decent.

How do you choose which area to export? The city is quite big.

[dabreegster]

It will take some effort to fix OSM before exporting something decent.

Definitely. I'm hoping A/B Street can provide motivation to rally OSM communities to mapping those sorts of details. Of course not only abst benefits from this; routing can be more precise, in particular. I personally think tagging for lanes is often low-quality in many areas because it's so hard to visualize the results.

How do you choose which area to export? The city is quite big.

I chop it up into different pieces. Some examples:



As you can see, the pieces don't have to perfectly partition the city; they can have gaps or overlap. Picking the boundaries totally depends on what you're trying to do -- some of the chunks of Seattle were chosen specifically for an experimental Santa game. Others were chosen because I wanted to study the possible effects of some changes to a certain area, so I used my own judgment to figure out what area might be relevant. And it's trial-and-error to tune the resulting file sizes and workaround bugs like #32

[dabreegster]

I filed #485 to focus on the crosswalk heuristics, btw