You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
#69 shows, that apparently our district is still working on adding those bike stands that where marked completed last year.
So now there is a case, where we might get stands in the non-existing-List that in fact are there.
The frontend handles those correctly by showing them as green (not blue), so the blue-status seems to be overwritten by green – which is great.
However, at some point we might need to re-check the non_existing-List against new OSM Data to clean it up.
IMO not a priority ATM; I created the issue FYI and for future reference.
The text was updated successfully, but these errors were encountered:
tordans
changed the title
Abgleich non_existing-Liste with existing bike stands
Re-check non_existing-Liste with existing bike stands
Jun 7, 2020
berlin_neukoelln;"404";"tordans";"An der Straße ist eine Baustelle. Die übrigen Bügel in der Straße konnte ich finden, aber vor dem Haus 37 oder 37B sind die Bügel vermutlich aufgrund der Baustelle abgebaut oder nie aufgebaut worden. Mapillary: aAqv6YEEQf-RI-5sFJyZCQ"
) I now think …
the blue markers should not overwrite the greens; maybe both should show up?
or we should only compare the green marker against bike stands that have no-access or access=yes; in this case (https://www.openstreetmap.org/node/7486811029) its access=permissive cause those are most likely private bike stands and not the city's.
#69 shows, that apparently our district is still working on adding those bike stands that where marked completed last year.
So now there is a case, where we might get stands in the non-existing-List that in fact are there.
The frontend handles those correctly by showing them as green (not blue), so the blue-status seems to be overwritten by green – which is great.
However, at some point we might need to re-check the non_existing-List against new OSM Data to clean it up.
IMO not a priority ATM; I created the issue FYI and for future reference.
The text was updated successfully, but these errors were encountered: