Question on crosswalks, inferred vs. mapped ones

[hungerburg]

I just started today with a local install. It all went smooth, importing my city. Main interest is pedestrian routing. Here crosswalks (highway=crossing on nodes) are meticulously mapped. The heuristics though infer a lot of them, where there are in fact none. While those in places where there is no crossroads simply are missing.

Is there a switch, to have (only/all) mapped crosswalks appear? Just switching off heuristics, would that result in no crosswalks? Will that be very complicated, to combine intersections etc. with mapped crosswalks only?

[hungerburg]

After having read some other issues on the subject. There are three types of crossings in OSM data (not always there is a highway=crossing on the node too, esp. with type 1 below):

1. crossing=traffic_signals
2. crossing=marked | uncontrolled | zebra
3. crossing=unmarked

The ones inferred by the importer should be of a fourth, internal only type. Perhaps, the importer can then look, if there is a mapped one very close, so it can mark it up. The unmarked and internal ones must not show as a zebra. No idea how to show them, but they should be shown somehow. (Remains the crossings somewhere along a road, where there is no intersection or split.)

Then, there is "crossing=no", this should make the importer of course drop the inferred crossing. (Imagine two cycleways, mapped separately, that join a road, where cycleways are mapped as lanes.)

Perhaps, the importer should also not infer pedestrian crossings over a five lanes highway=primary, unless there is one mapped at the location. From the looks, there is also a crossing inferred, where the number of lanes changes.

In my country, people may cross streets, wherever they deem that to be safe, but not closer than 20m to a zebra crossing, which they are then ordered to use. That may be hard to model for the game, it is not of much importance either. Mostly, that affects only the last meters of a trip, e.g. if there is a sidewalk only on the left side of the street, but the target is on the right side.

So these are my ramblings on how to make the OSM data used a bit more in constructing the base of the game.

[dabreegster]

Thanks for writing up how the OSM schema should map over! This is a bit of a deep rabbit hole, but it's long past time to write up some of these ideas. There are two related issues of how to model sidewalks and how to model crosswalks, and though they're a bit hard to detangle, I'll try to mostly focus on the second here.

Is there a switch, to have (only/all) mapped crosswalks appear?

In short, not yet.

Why heuristics in the first place?

There are three reasons why I've mostly been ignoring sidewalk and crossing data from OSM.

1) In Seattle where lots of my effort has been focused so far, there's separate ways and lots of detail in some areas, but it just cuts off: https://www.openstreetmap.org/#map=19/47.63940/-122.31783 Distinguishing cases where there's legitimately no sidewalks from areas that haven't been mapped yet is impossible from just looking at this data, to my understanding. That of course should not preclude creating a "heuristics / use OSM data" control.

2) There are many suburban local streets that legitimately have no sidewalks, but I still wanted pedestrian routing to work. The workaround has been to model a very skinny walkable "shoulder" lane on the edge of those streets.

3) When sidewalks are marked as separate ways in OSM, that causes lots of headaches for the A/B Street map model. See https://github.com/a-b-street/osm2streets/issues/59.

In Krakow, we have disabled the "sidewalk as a lane of the main street" and are using the separate ways. The config is https://github.com/a-b-street/abstreet/blob/324ef84b3cf6640e77b086853971fb1c56c39283/importer/config/pl/krakow/cfg.json#L6. You can try it at http://play.abstreet.org/0.2.64/abstreet.html?--dev&system/pl/krakow/maps/center.bin (or better, just download it from your local version). The crosswalk heuristics are still in place here, but since the sidewalk lanes are now separate from the street, the crosswalks sort of wind up in the right place: There are many bugs with this "no inferred sidewalks" mode, and I haven't put in effort here in at least a year.

The ideal model

Let's assume we're still treating sidewalks as the outermost lane of streets, for the reasons given in a-b-street/osm2streets#59. How should crosswalks be represented? I think we need to split the current one type into at least two.

The unmarked and internal ones must not show as a zebra. No idea how to show them, but they should be shown somehow.

Agreed. There are many places where it's legal and typical for people to cross, but there's no markings in reality. I think in A/B Street these should still be visually rendered, to distinguish from places where legitimately there is no legal/in-practice crossing. Maybe we could just dim the current white markings.

people may cross streets, wherever they deem that to be safe, but not closer than 20m to a zebra crossing, which they are then ordered to use

This is hard for 3 reasons:

1) Not sure how to visually render/communicate this is a possible thing to happen

2) It complicates pathfinding; the graph needs lots of extra connections to link sidewalks outside of intersections. There could be some tricks to dynamically fill these in or post-process a path that uses the nearest zebra crossing.

3) The simulation layer handles conflicting movements only in intersections (except for a few recent changes with vehicles lane-changing or exiting driveways). We'd have to extend this to handle a pedestrian figuring out when it's safe to cross mid-block and mark off the appropriate part of the street as temporarily blocked.

So I'd say for now, the only modeling change I'd like to consider is having two types of crosswalks -- marked and unmarked.

OSM import, non-heuristic mode

I propose a new per-city importer config to use OSM crossing data and disable the heuristics. It'd only be appropriate to enable this for places with the data thoroughly mapped. Probably to start, we'll find cases where this disconnects part of the pedestrian routing graph, and that might be an acceptable start. Will have to see what problems happen in practice.

Perhaps, the importer can then look, if there is a mapped one very close, so it can mark it up.

I think this is probably the simplest approach to start with.

1) The importer generates all possible crosswalks, using the current approach. 2) We collect all of the polylines representing crosswalks in OSM 3) We filter out all of the generated crosswalks by matching each OSM polyline with one of them

So the crosswalk geometry / placement still comes from A/B Street and matches its model of sidewalks as lanes of a road. But it snaps the more detailed OSM crosswalk geometry and uses that for filtering.

Drawing OSM footways on top of abst: In this case, all 4 crosswalks at both intersections have a crossing mapped, so the abst heuristics are already correct. For the service road in the middle, the east/west crosswalks are inferred because there's a highway = footway crossing over. In this new mode, there would be no north/south crossings here, because there's nothing in OSM.

Related issues

a-b-street/abstreet#485 is about automatically pruning the auto-generated crosswalks, without looking at OSM.

a-b-street/abstreet#517 is about making pedestrians wait a few seconds before entering a crosswalk. Right now they only "see" a vehicle if it's right at the boundary of the crosswalk. It's "invisible" even if it's 0.5 seconds away!

a-b-street/abstreet#70 is about being able to edit turn restrictions at an intersection. Relatedly, we need a tool to let people modify where marked and unmarked crossings are.

I will aim to start on some of this work this week, but no promises, very overloaded right now.

[hungerburg]

The more openstreetmap data is used, the less in-game editing necessary, shouldn't that hold? Just two quick observations:

So I'd say for now, the only modeling change I'd like to consider is having two types of crosswalks -- marked and unmarked.

That should be pretty good. I think lots of "unmarked" crossings in the OSM data came to be by "inferrence" by the mapper just as well, so they are not so different. The ones of type crossing=traffic_lights often are already matched, because of the traffic_signals there.

I suggest to draw the "unmarked/inferred" ones as two thin lines, perpendicular to the street. I have seen that on pictures from the US - where the paint marking on the driveway extends and connects the sidewalk footways.

We collect all of the polylines representing crosswalks in OSM

In the town of my import, sidewalks are mostly mapped as properties on the road, in the abst friendly way, so to say. Consequently, crossings are not lines, they are just nodes. Such crossing nodes are present, when sidewalks are mapped as separate ways too, and I guess that is how it is supposed to.

Legally, a crossroads here also creates unmarked pedestrian crossings with some level of protection, yet, unlike what the importer infers, in a T-type crossroads, not three of them, but only one, on the down-stroke edge of the T, in the joining road.

Legally too, if there are no sidewalks, people are to walk on the shoulder of the road, so the workaround you mentioned is spot on here.

[dabreegster]

In the town of my import, sidewalks are mostly mapped as properties on the road, in the abst friendly way, so to say. Consequently, crossings are not lines, they are just nodes.

Ah, that's not a variation I've come across. Mind linking an example area in OSM so I can test accordingly?

[hungerburg]

Well, here mappers a lazy, in the US, I know only of San Francisco, where sidewalks are predominantely mapped as properties. In the UK, Germany, France, Austria, also in South America, this mapping is widely used. It plays nice with a router for blind people, available for part of the region, they do something quite similar to A/B-Street I guess. Here a reduced geojson of the area of my import

{ "type": "FeatureCollection", "features": [ { "type": "Feature", "properties": {}, "geometry": { "type": "Polygon", "coordinates": [ [ [ 11.365699768066406, 47.259194168186234 ], [ 11.415996551513672, 47.251620889947624 ], [ 11.45547866821289, 47.277132689150854 ], [ 11.400032043457031, 47.28633255817871 ], [ 11.365699768066406, 47.259194168186234 ] ] ] } } ] }

Still, a pedestrian crossing must be a node on the street everywhere on OSM, no matter how sidewalks are collected; that is what the Wiki says, if I got that right.

PS: OSM-France shows crossings on their slippy map tiles in close zooms, eg. http://tile.openstreetmap.fr/?zoom=19&lat=47.27613&lon=11.40106&layers=B00000000FFFFFF - I spot crossing=* nodes in Seattle too.

Reading up on the subject, marking crosswalks mostly serves as a means to guide pedestrians, to make them prefer marked locations to cross some street over just crossing anywhere. So differentiating might prove worthwhile in a traffic simulation game.

[dabreegster]

I started a configuration option for this. It looks at highway=crossing nodes, snaps the crosswalk to the closest end of the road, and filters the auto-generated crosswalks accordingly. Results don't look good in some test areas around the US and Germany that I tried, but I'll see if I can improve it in your area.

One problem is deciding which end of a road segment a crossing should apply to. In this example, the crossing is for the intersection with the traffic signal: But when just looking at the position of that point on the line segment between the traffic signal and where that southern service road starts, the point is closer to the service road. So the crosswalk is placed on the wrong end:

[hungerburg]

That is bad :( One might say, it is an edge-case, but still, there is nothing in the OSM data, to correctly associate this very crossing with its proper location in the A/B Street tileset; at least, where there are no "footway=crossing" mapped. I don't see my area special. In Germany and the UK, France, there you'll find many similar areas. They can't be seen from looking at OSM-Carto, but they are there. Is there an "easy method" to turn on the switch when importing from the application, a file with default importer settings?

[dabreegster]

there is nothing in the OSM data, to correctly associate this very crossing with its proper location in the A/B Street tileset

Agreed. This is another reason why I'd love to see a proposal for tagging the entire area of an intersection gain popularity. There may be some heuristics that can help here, though. For instance, the distance on the line segment looks closer to the service road, but that's before the importer builds an intersection polygon for both ends and "trims" the line segment of the road in between. After doing that, maybe the crosswalk will look closer to the right side.

Is there an "easy method" to turn on the switch when importing from the application, a file with default importer settings?

Not yet, I need to add more command-line flags to the importer tool, then add checkboxes (probably hidden or labeled as "advanced") to the UI. I'll make more progress on the heuristics in the area you posted and add the UI before the next release.

[hungerburg]

The junction tag sounds interesting, there is a reduced version that has found approval, https://wiki.openstreetmap.org/wiki/Tag:junction%3Dyes - It should be sufficient to solve the case above? Provided someone goes all the way to code that. In my area, I suspect that it is mostly used to put names on the standard map view, so any extra use was cool. Don't know if there are routers that use it for turn by turn instructions. Anything that makes sense for both the game and its openstreetmap data source should be done in OSM :) So it should not require extraordinary efforts, because then it will takes ages or stay incomplete forever.

https://www.openstreetmap.org/way/877926704 is now two intersections in A/B-Street. There are two superficial inferred crossings in the picture, there are four OTG crossings missing in the picture. There is at least one "sidewalk=no" missing in the data ;)

[dabreegster]

The new build will let you toggle the option in the UI: The results in Innbruck have many issues. There are no crossings in many places where I'd expect them: This is near https://www.openstreetmap.org/node/31865599, I don't see any crossings mapped. Once A/B Street models unmarked crossings, it could place them here, effectively making this new option just "downgrade" crosswalks. But that doesn't really change much; pedestrians will still cross using the unmarked crossings and likely create unrealistic simulation behavior. I'm not sure how to distinguish missing data from a legitimate lack of marked or unmarked crossings.

But also the algorithm doesn't seem to be picking up https://www.openstreetmap.org/node/4850603936 at all, not sure why yet.

[hungerburg]

This is the area in french style map with crosswalks shown http://tile.openstreetmap.fr/?zoom=19&lat=47.26926&lon=11.40883&layers=B00000000 - there are no more. There is no data missing. This is just a small city, I know it quite well. Changes on site reflect very quick in openstreetmap. I'm not the only one mapping that stuff. I don't think that is much different in Seattle, is it?

The change in behaviour, to make the simulation more realistic rather than less, might be, that marked crossings pose an incentive for the built in router to use them, especially the ones with traffic signals, over the others, but never to prohibit inferred crossings. A tool for the traffic planner so to say. In the wild, people cross most anywhere, with strong preference for marked locations though.

The crossing on the other end of the street segment of the missing one appears. From looking at https://github.com/a-b-street/abstreet/commit/fd10ea74dcee86464c99adc610da6ea1cfb0051c I guess, that even a "crossing=unmarked" would give reason to show a marked crossing? Marked ones can be called "marked | uncontrolled | zebra", but never "unmarked". The missing one is not on an end-point either -- something that likely occurs in the data!

The latest download does not have the switch. Will wait.

[dabreegster]

The change in behaviour, to make the simulation more realistic rather than less, might be, that marked crossings pose an incentive for the built in router to use them

I mostly agree. The two types of crossings can be penalized differently for routing. And when the simulation supports more realistic behavior for when pedestrians start to cross, they can be configured to wait longer at unmarked crossings for vehicles to clear out.

I'd still like to fix some of the really ridiculous situations like all the inferred crossings near a traffic signal or over a major road: There's just too many crossings close together. But I think the approach could still be to

1) Model unmarked crossings as described above 2) When configured, use OSM data to downgrade marked crossings into unmarked 3) Work on a-b-street/abstreet#485 and also be able to use automatic heuristics for downgrading

I guess, that even a "crossing=unmarked" would give reason to show a marked crossing?

Right now yes, but A/B Street just models one type of crosswalk. Next step for me is to distinguish the two types.

The latest download does not have the switch. Will wait.

It'll be in the next Sunday build

[dabreegster]

I started the split between zebra and unmarked crossings. Haven't tuned the routing penalty yet or made the simulation realistically use them. But now instead of deleting crosswalks not matching an OSM node, just downgrading them to unmarked. The rendering isn't great, but here's a start:

[hungerburg]

Looking forward to the new build; Recently I learned, that the pictured rendering in Canada and parts of the US actually shows a marked crosswalk . Not so easy to mark up in a map something that is unmarked in the world. You suggested a dim version of the stripes, I tried with the gimp paint program, fully black ones do too.

[dabreegster]

https://github.com/a-b-street/abstreet/releases/tag/v0.3.0 has the new options.

You suggested a dim version of the stripes, I tried with the gimp paint program, fully black ones do too.

The thin grey stripe in the picture above is how this is shown currently. Open to suggestions. Drawing something that's unmarked is a bit of an oxymoron, but...

[mdejean]

In terms of heuristics I did something where I hid crosswalks at stop sign intersections where at least one straight movement does not stop: https://github.com/mdejean/abstreet/commit/6969acb806ed10efe860bc8c932c036d37d801af

straight turn type is kind of arbitrary unfortunately, but this basically had the results I wanted.

[dabreegster]

In terms of heuristics I did something where I hid crosswalks at stop sign intersections where at least one straight movement does not stop

I'll try this heuristic out. If it works well, we could add it late in map importing (after stop signs have been generated) and use it to downgrade crosswalks to the new TurnType::UnmarkedCrossing. That'll give us the new rendering, the penalized routing cost, and (eventually) more realistic priorities between vehicles and pedestrians trying to cross.

Basing this off the stop sign heuristics is a bit funny, since those heuristics also have issues, but it's still easy to understand overall. And it'd be intuitive to edit a stop sign in the UI and see the crossings change accordingly.

[hungerburg]

The term oxymoron came to my mind also, the life of cartographers. Your first idea was not so bad - when I wrote, fully black, I meant, black stripes, instead of white ones. Nowhere in the world - as far as I know - crossings are marked with black stripes, so it should be immediately obvious to everybody, that these are not marked crossings.

From the new build I collected some places, where the current algorithm does not work accurately. On the cases below

1 is a mystery, just as 2. Is there another place in the code, that creates crossings? 3 is quite obvious - it will be difficult to decide, to which segment the crossing belongs 4 is mapped in a way, so that the question in 3 should be easy to solve, yet…

1 There is no marked crossing mapped neither near nor far https://www.openstreetmap.org/way/533973754

2 There are no marked crossings mapped on the inroads of this circle https://www.openstreetmap.org/way/145113387

3 There is a single marked crossing mapped on the node of a 4-way Y junction https://www.openstreetmap.org/node/848914169

4 There is a marked crossing mapped, close to a 4-way Y junction https://www.openstreetmap.org/node/2481519341

[dabreegster]

Nowhere in the world - as far as I know - crossings are marked with black stripes, so it should be immediately obvious to everybody, that these are not marked crossings.

Thanks, this is a good suggestion. The thin lines now look really messy. I'll try this out...

From the new build I collected some places, where the current algorithm does not work accurately.

I made two fixes. The first affected some examples in Seattle where I was testing, but probably not near Innsbruck -- it was due to part of the importer removing redundant points (where the angle remains the same on the line segment on both ends), but then some of those points being crossing nodes. The other fix is a quick hack around cases where the map model doesn't know what roads a crosswalk covers. Results are better with these fixes, but still not correct.

There is no marked crossing mapped neither near nor far

Fixed: This was due to the second bug. Since there's no walkable lane on the other side of this road, the logic to figure out what road is crossed fails: https://github.com/a-b-street/abstreet/blob/244e96542769fd6e63be58500e27e893804f65ac/map_model/src/objects/turn.rs#L268 Need to come up with something better here.

There are no marked crossings mapped on the inroads of this circle

Same problem, fixed.

There is a single marked crossing mapped on the node of a 4-way Y junction

Not quite fixed. For some reason the crossing node is snapping to the other end of the road

There is a marked crossing mapped, close to a 4-way Y junction

Fixed. Actually I guess the first change (redundant internal points) did apply here.

[hungerburg]

Case 3 I am about to make unambiguous in data, before next Sunday :) Are there even roundabouts where pedestrians cross through the inner? Not sure, but I think I never stumbled upon that.

For some reason the crossing node is snapping to the other end of the road To spare you some headache - there is a mid-block crossing mapped in-between, less than half way from the intersection shown, I strongly believe, this is the one to jump here.

[dabreegster]

Case 3 I am about to make unambiguous in data

This one's https://www.openstreetmap.org/node/848914169, right? Already looks fine in OSM. Probably a bug on my end.

before next Sunday

If you want to try things out sooner and have some command-line experience, building from source isn't too bad after the initial investment. But probably only makes sense if you want to work on the code too.

Are there even roundabouts where pedestrians cross through the inner?

Not that I've seen, besides huge attractions like the Arc de Triomphe. And that's modeled as a pedestrian area polygon anyway

[hungerburg]

A download per week is fast enough already. Arc de Triomphe can only be reached through underpass. The Charles de Gaulle roundabout is mapped as a 12 lane primary highway, good luck when trying to cross :)

This one's https://www.openstreetmap.org/node/848914169, right? Already looks fine in OSM. Probably a bug on my end.

I cannot think of a way to decide the direction of the crosswalk, when it is on the node of a crossroads. OSM france tiles in such cases do not render a zebra but a pedestrian symbol instead. BTW, opencyclemap renders crossings as a yellow dot, the ones with lights as a green dot.

This https://www.openstreetmap.org/node/8487288852 might also be problematic - it sits at the split point of a small road and perhaps snaps to the crossing to the north. Maybe, the search for mapped marked crossings should stop 20 or 30 m away from a junction, so mid block crossings do not end up in the wrong place?

[hungerburg]

Not much time spent on A/B Street this week, just enough to tell, that the number of superficial marked crossing practically dropped to zero, some are missing. Still pondering how to play the game or how to pitch the simulation to the local administration, so they can stop relying on google to calculate pedestrian travel times :)

[dabreegster]

Just recording https://wiki.openstreetmap.org/wiki/Crossings, a nice new summary