jakecoppinger / better-intersections Goto Github PK

This would enable a "Contribute measurement for this exact crossing" link on the intersection stats page (or popup).

The node id would be prefilled in the OSM Node ID textfield and the map select step would be hidden or skipped.

Example url would be /contribute-measurement/12345 where 12345 is an example OSM node ID.

Would help pinpoint if issues arise, or what the form looked like for a particular measurement.

(we already preference making new fields optional so submissions prior to the change have null rather than 'no')

This field is in the DB and types but currently doesn't exist as a form field. It was previously included in the Google Form but with the move to the custom form I excluded it to minimise the number of required fields.

I think it makes sense to add it back in but as an optional field.

Copy text on the Google form was

Optional: What code is on the traffic light control box?
Usually a number on yellow background, on a metal box near the intersection.

Open to ideas. Perhaps a horizontal scroll would be the go.

The info box (top left) takes up a lot of space. This could be shown at first, then minimised on map move.

Ethan's bike map (https://sydneybikemap.ethan.link/) is a really good design to follow here.

Cloudflare reports around an 8mb bundle size. I haven't looked into the cause of this - we might be able to achieve some easy wins by adjusting some build config settings or library imports.

If it's not a simple fix I don't think we should stress too much - time to map pin load is more dependant on the OSM node requests.

See discussion in #6

Possible algorithm would be when nodes are connected by a way in between a dual carriageway (where both one-way roads have the same name), AND either node has at least one measurement with two_stage_crossing=false (or whatever the field ends up being called), AND neither node has any measurements with two_stage_crossing=true, then group them on the map and on the intersection stats page. This ensures intersections measured before #6 is added aren't automatically grouped (though they may be two stage crossings).

This is fairly high hanging fruit and so isn't high priority!

I think this may be possible using IP address as a course location, so that users in Canberra (for example) would see the map load there instead of Sydney.

As Cloudflare proxies the frontend, we may need to look into whether Cloudflare provides this functionality.

No intersection Pins are showing. Checked by looking in Sydney CBD. Additionally checked across two seperate Android devices.

'Cycle Length' is not rounded when I click on an intersection pin from the map.

It shows e.g. "143.42700000000002 sec.".

This could be rounded maybe to 2 decimal places?

Currently this tool only takes measurements for nodes, that is a single traffic light.

Ideally it would be able to identify two traffic lights on the same OpenStreetMap pedestrian way which would indicate a dual carriageway crossing. Additional metadata could be collected to record whether the pedestrian can cross in one green phase, or is required to wait an entire cycle and use 2 green phases.

For example: https://www.youtube.com/watch?v=JBZkpmW91PY

It takes about twenty seconds to walk across Antill Street.
At this intersection, it takes five minutes to legally walk from the north side of Antill Street to the west side of Cowper Street.
The first green pedestrian signal phase allows only enough time to cross to the median on Antill Street.
The green pedestrian signal phase, in the next cycle of the traffic lights, allows people to complete crossing to the east side of Cowper Street. They must then wait until a green signal allows them to commence crossing Cowper Street.
The that green pedestrian signal phase allows them only enough time to cross to the median on Cowper Street. They must then wait on the median until the green pedestrian signal phase, in the next cycle of the traffic lights, allows them to complete their crossing to the west side of Cowper Street.

Ideally users wouldn't be required to sign into their Google Account to them submit form timings.

A better UX for the form requires a custom form. I'm hesitant to implement a form without some sort of gating via email (or phone number) to prevent spam from a single individual.

Passwordless sign in would accomplish this, but would likely involve architecture this into a full stack app (rather than static). Any alternative ideas are welcome too!

Timestamps are stored as UTC ISO8601 timestamps, and are currently displayed as such.

With a couple of lines we should be able to import a date formatting library and display as a more "friendly" time in the popup on the frontend.

Ideally this would use the location coordinates to find the local timezone, otherwise displaying in Sydney time should be fine.

Ideally it would look up the Sydney timezone (AEST vs ADST) at the time of capture, but displaying in the current Sydney time would be better than UTC. As long as we include UTC+11 (or whatever the offset is) the user is able to convert if it's incorrect.

To improve first load speed and reduce load on the OSM API, we could download the node locations at build time.

I like the idea of building almost as a "static cache", and if there's a cache miss we still hit the API (so new measurements still load between builds and deployments)

Probably just needs the z-index changed!

Something as similar as <p>Loading data...</p> in the top left panel would do the job!

Will likely need to call getIntersectionMeasurements() and download to a .csv. Add copy text and link on about page.

It would be very useful to be able to filter points by how many lanes are at the crossing, or only showing long cycle times.

This could be accomplished by adding another field into the state which is a subset of all pins.

See discussion in #6 for possible algorithm

We may need to use react portals: https://react.dev/reference/react-dom/createPortal

I don't think the form is being fully wiped on submission; some fields (the uncontrolled fields) still have content in them.

I'm seeing OSM node disappear more often than I expected would happen. This issue is to track a fix for storing coordinate locations as well as OSM nodes to be able to find node replacements manually if necessary.

To be crystal clear; this is to store the coordinates of the traffic signal node (from OSM) at submission time, not to store the user's location.

Colour scheme for timings leaves a lot to be desired. Perhaps green should be best practice and shades of orange/red/purple/back up to a constant of the worst timing measured.

On mobile (Chrome 120, Android 14, Pixel 7 Pro), the "Filter by cycle time" slider can be set by tapping the location on the slider.

But I can't tap and hold to drag the slider position like on desktop.