I will begin by adding a radio button to the form to indicate if its a two stage crossing or not. The next stop would be to add that to the measurements in the backend, which would require a new boolean field in the schema and db

Yep sounds good!

The already existing measurements will have the value 'False' for this.

I would recommend an optional string field, as this lets us add further values in future. We might start with 'yes' | 'no' | null, but in future it could be 'yes' | 'no' | 'unknown' | 'green-not-long-enough' | null etc. The benefit of making it optional is that existing measurements have null rather than 'no', making it very explicit they may be two stage crossings but it hasn't been checked. (A version field would also help with making sense of changes in future - I created #23)

How would you want to proceed with schema changes and access ?

You can likely start from copy and pasting the form component and .sql entry for is_scramble_crossing text and go from there. If you can try setting up your own DB using the instructions that would be ideal, if not I'm happy to take the WIP PR and verify.

You'll likely hit issues setting up your own DB for the first time as nobody has done that before - please let me know and I can help out and improve the documentation!

For future state

If the user submits a form and marks the radio as true for a two step crossing, we want to recommend another node to contribute to (this other node should be connected to the previous node by a 'crossing' or 'sidewalk')

Yep this sounds great! If there is only one other highway=crossing node on the crossing or sidewalk way, we could create a direct link to contribute a measurement for that other node (I created #24 for this which also has other benefits). Otherwise I think it would be safe to just encourage another submission and let the user select using the map (or just a detailed text location description) as the OSM data may not be as detailed as we'd like.

That algorithm seems right! I've created #26 to track that issue. I've also created #25 for possible grouping improvements.

from better-intersections.

Hey, I’ll take this up

from better-intersections.

Hey Jake, I was working on this yesterday and needed some clarity. From what I have read on the internet, there are two types of dual carriageway crossings -

1. When there is a pedestrian light in the middle - These basically have two pedestrian lights - one from the start point to middle and one from middle to end.

2. The other kind is when there is no light in the middle but only a button. The light exists only on the other side of the crossing. You may or may not be able to cross in one iteration of the light. This is the case shown in the above video.

The first actually just includes two nodes or two pedestrian lights and our app can handle. But for the second we can ask the user if they were able to cross in one iteration and the timings. And this can be shown as one marker with the additional metadata. This requires an additional field in the db which indicates if two iteration were required or one and the timing for each - further another field in the form ?

"Ideally it would be able to identify two traffic lights on the same OpenStreetMap pedestrian way which would indicate a dual carriageway crossing. "

• I am not sure what you meant by this ? Would be great if you could explain a bit more ?

from better-intersections.

Hey Ayaan,

Thanks for picking this up! It is indeed a tricky one.

The first actually just includes two nodes or two pedestrian lights and our app can handle.

Yep I agree.

But for the second we can ask the user if they were able to cross in one iteration and the timings....This requires an additional field in the db which indicates if two iteration were required or one and the timing for each - further another field in the form ?

Yep I partly agree, I think this would be a flexible way of capturing this information which might not easily fit into a more rigid schema. I don't think we should request a timing for each in the same form if more than one cycle is required to cross - I would prefer we direct the user (or provide a link) to contribute a measuremnet for the other node nearby. (or if a node isn't present, using the location field).

The bit where this gets tricky I think is that a sidewalk or crossing way (path) across a dual-carrigeway road on OpenStreetMap will have two nodes, one for each direction of the road, but not necessarily be a two stage crossing. By this comment

"Ideally it would be able to identify two traffic lights on the same OpenStreetMap pedestrian way which would indicate a dual carriageway crossing. "

I was initially thinking perhaps we should add support for specifying a crossing way (path) rather than a single point.

Not only would this be trickier architecturally, and I'm not sure if it would be desirable either. If we:

• assume OSM can't determine whether it's a "two stage crossing" or just a one stage crossing across a dual carriage way
• allow users to choose a node or a way

then some users might select a point, some a way, and the data will be very messy.

I think I would prefer we only capture against nodes (as we do currently) and a possible post-processing step (whether just when doing analysis or even on the intersection stats page, or even to filter which points are shown as candidates to contribute to). I image this as as something like:

if there if no measurements flagged with "unable to cross in one cycle":
  find (nodes connected by a `highway=crossing`) or (nodes connected by `highway=sidewalk` and road names are the same [dual carriageway roads have the same name both directions]):
  group all measurements [for the purposes of averaging] from all nodes in the above set [or we only display one node from each set]

for this issue, I would recommend just biting off the "add a radio button whether it's a two stage crossing" part!

from better-intersections.

okay I think I got it.

I will begin by adding a radio button to the form to indicate if its a two stage crossing or not. The next stop would be to add that to the measurements in the backend, which would require a new boolean field in the schema and db. The already existing measurements will have the value 'False' for this.

How would you want to proceed with schema changes and access ?

for this issue, I would recommend just biting off the "add a radio button whether it's a two stage crossing" part!

As you recommended - this is the extent of this issue for now

------- but to just understand for the future

If the user submits a form and marks the radio as true for a two step crossing, we want to recommend another node to contribute to (this other node should be connected to the previous node by a 'crossing' or 'sidewalk'). This node is supposed to represent the second stage. I am unsure about when we make this recommendation ? - on the intersection stats page ?

if there if no measurements flagged with "unable to cross in one cycle": find (nodes connected by a highway=crossing) or (nodes connected by highway=sidewalk and road names are the same [dual carriageway roads have the same name both directions]): group all measurements [for the purposes of averaging] from all nodes in the above set [or we only display one node from each set]

The objective of this piece of pseudo-code would be to group observations when the crossing was not a 2 step but since there are 2 nodes, 1 for each side of the crossing - measurements for the same crossing might have been associated with different nodes.

from better-intersections.

Two stage crossing support added in #27

#26 is for improving UX to encourage measurements at the other stages of two stage crossings, and #25 is for grouping of measurements at two stage crossings.

from better-intersections.