streetcomplete / StreetComplete

Easy to use OpenStreetMap editor for Android
https://streetcomplete.app
GNU General Public License v3.0
3.82k stars 348 forks source link

New Quest: public_transport route_ref #2826

Open martin-scholtes opened 3 years ago

martin-scholtes commented 3 years ago

General

Affected tag to be modified/added: route_ref Question asked: Which lines depart from this platform?

Checklist

Checklist for quest suggestions (see guidelines):

Ideas for implementation

Element selection: All objects that have the tag public_transport=platform.

Metadata needed:

Proposed GUI: The object is highlighted, the name of the stop is to be displayed. Then the question which lines leave here; enter the letter-digit combination.

westnordost commented 3 years ago

What if there is no sign?

TurnrDev commented 3 years ago

What if there is no sign?

flag=no has been used in the UK to specify that there is no bus stop flag/sign, but it's not widespread. Might be an idea to add a quest for this?

westnordost commented 3 years ago

There may be a bus stop sign but no board that says which bus routes go through there

martin-scholtes commented 3 years ago

If there is no signage or an overview of the lines on site, then one should set route_ref:signed=no, analogous to the opening hours.

Another thing that occurs to me is that the task should also be checked at regular intervals (1 year).

matkoniecz commented 3 years ago

I admit that I am suspicious about value of bus route mapping in OSM and it is seems to be adding more duplication on top of that.

martin-scholtes commented 3 years ago

My thought was that you can check whether the bus routes that are mapped at the stops still belong there by storing the routes in the current location.

peternewman commented 3 years ago

I admit that I am suspicious about value of bus route mapping in OSM and it is seems to be adding more duplication on top of that.

How else do you know where a bus goes otherwise?

matkoniecz commented 3 years ago

How else do you know where a bus goes otherwise?

Not from OSM data. But given lack of timetable data and how quickly it becomes outdated having just route in OSM is of quite low utility

peternewman commented 3 years ago

Not from OSM data.

Yeah unfortunately as Citymapper proves, that's really hard: https://citymapper.com/

I suspect for timetables the best you could hope for is having the right ID/ref to be able to link to something external.

But given lack of timetable data and how quickly it becomes outdated having just route in OSM is of quite low utility

Surely given which buses stop at which stops (although I guess it might be better as a relation possibly), you could treat them as roads, find the nearest to you and your destination then you've got the route you need to take. Obviously it potentially won't be as optimised time wise as if you knew the timetable, but if you walked to the nearest stop and waited you'd get to your destination.

matkoniecz commented 3 years ago

Given that some bus lines run only on weekdays and some only on weekends, or with 8 hour Harris between runs: route without timetable is of basically no utility

There is some value in it but...

jtracey commented 3 years ago

route without timetable is of basically no utility

Some uses off the top of my head:

I'm sure others could think of more if they tried.

mnalis commented 3 years ago

I agree with @jtracey that public transit routes and stops mapped in OSM are quite useful (at least in my country they are).

But I am not very sure if quest like this would be more useful than dangerous, due to complexity issues involved (some are mentioned above, the other like mixing and matching different schemes are not). In many places [citation needed] that data is curated and needs much higher overview than just what is seen on the ground (eg. in city of Zagreb, we verify OSM data versus official GTFS data, and often find one or the other wrong - but really one often needs all 3 data sources to mark the nodes correctly. We do report errors back to route operator, and they do seem to fix them).

So I could agree the quest might be useful in places where the public transport route is not mapped in OSM, but only if the nodes/ways are not present in any relation (as routes indicate higher level of involvement of the community, and the potential harm is very high there; whereas if there is no data present at all adding some won't do much harm, even if it is incomplete/obsolete).

westnordost commented 3 years ago

Furthermore I'd say that recording this information might help maintain the map in the same way recording the location of stop, city limits etc signs does. It is one "source" information for keeping other data up to date, such as maxspeeds in that case or bus routes in this case.

Lee-Carre commented 3 years ago

There may be a bus stop sign but no board that says which bus routes go through there

passenger_information_display=no

peternewman commented 3 years ago

There may be a bus stop sign but no board that says which bus routes go through there

passenger_information_display=no

The wiki seems to make it reasonably clear that's for an electronic display: https://wiki.openstreetmap.org/wiki/Key:passenger_information_display

Compare say: Bus stop no routes

Bus stop routes

Neither have an electronic passenger information display.

I'd say what we're talking about is more of a route board, not that there seems to be a tag for that.

Lee-Carre commented 3 years ago

There may be a bus stop sign but no board that says which bus routes go through there

passenger_information_display=no

The wiki seems to make it reasonably clear that's for an electronic display: https://wiki.openstreetmap.org/wiki/Key:passenger_information_display

[truncated]

Neither have an electronic passenger information display.

I'd say what we're talking about is more of a route board, not that there seems to be a tag for that.

Then Key:departures_board.

Though, personally, this seems a bit of a fudge in terms of tagging; a real-time electronic display should be a sub-type (=real-time or =electronic) of the same key used for either printed or electronic. In terms of helping the passenger, what's important is the information, not how it's displayed. But, alas.

peternewman commented 3 years ago

I'd say what we're talking about is more of a route board, not that there seems to be a tag for that.

Then Key:departures_board.

But the details of that are ALL timetables, this is more basic.

In terms of available information, from least to most (but also frequency it changes/becomes incorrect, from slowest to fastest):

  1. Just a bus stop sign
  2. List of the route numbers that stop here
  3. Where the routes go to (either a map, or list of stops, either partial or full)
  4. When they are timetabled, either frequency or times
  5. An electronic display with a countdown to the next bus

From what I can tell, departures_board is for 4 and 5, whereas this quest is just about 2.

Though, personally, this seems a bit of a fudge in terms of tagging; a real-time electronic display should be a sub-type (=real-time or =electronic) of the same key used for either printed or electronic. In terms of helping the passenger, what's important is the information, not how it's displayed. But, alas.

Yes, and people have made that comment on the talk page: https://wiki.openstreetmap.org/wiki/Talk:Key:passenger_information_display

Lee-Carre commented 3 years ago

the details of that are all timetables

I saw nothing to that effect in the wiki.

Even if so, then the tagging scheme needs to be sorted out, first.

Lee-Carre commented 3 years ago

Thinking more broadly, for a moment, if the problem of ‘does this stop have any info about routes & departures for passengers?’ is solved, then that could become a conditional for this route_ref quest; only ask for stops which have some kind of info displayed, ignore the ones which don't.

peternewman commented 3 years ago

the details of that are all timetables

I saw nothing to that effect in the wiki.

Erm which bits did you find that didn't say that:

displaying information about scheduled services, real-time info or both. Timetable printed... Timetable without precise time... A realtime departures board... No timetable

Even if so, then the tagging scheme needs to be sorted out, first.

Agreed, sadly as with many of these tags they cover 95% of the scenarios but not all of them, which I guess is the real challenge with trying to map the world.

Thinking more broadly, for a moment, if the problem of ‘does this stop have any info about routes & departures for passengers?’ is solved, then that could become a conditional for this route_ref quest; only ask for stops which have some kind of info displayed, ignore the ones which don't.

Agreed, although you'll need a quest to tag that as well, otherwise the vast majority of bus stops would be ignored as this info wouldn't have been tagged. Or I guess you could ask it for <magic new tag>!=no.

jtracey commented 3 years ago

This all sounds over-engineered to me. If the rare bus stop lacks visible route refs, the user can tell StreetComplete to ignore that stop. If that's the norm, or even just frequent, they can disable the quest. We don't do anything fancy for the ref tag, and I doubt that is significantly more common than visible route refs. In fact, for the intercity bus service here, it's the inverse: all stops have route refs, few have stop numbers visible (municipal routes always have both).

TurnrDev commented 3 years ago

We don't do anything fancy for the ref tag, and I doubt that is significantly more common than visible route refs.

Where I'm from most stops will have name, id (ref + naptan:NaptanCode) and maaaybe the logo of the operator of one of the routes that stop there. But never seen a route shown unless it's on the timetable itself

jtracey commented 3 years ago

Again, then you can disable the quest. This isn't unusual for StreetComplete, there are plenty of quests whose applicability are context-dependent that are left to the user to decide. Plenty of areas don't post visible addresses, some countries don't have street names as part of the address, tactile traffic light indicators don't exist in my country, etc., etc..

peternewman commented 3 years ago

This all sounds over-engineered to me.

Quite possibly, and just tagging something like route_ref:signed=no may be deemed acceptable, although there are currently no uses of that tag anywhere, so it depends how much :signed counts as an existing suffix applicable to any key.

We don't do anything fancy for the ref tag, and I doubt that is significantly more common than visible route refs.

Yes we do, it tags it as ref:signed=no so it the next user won't be asked about it (which is currently the key difference here): https://github.com/streetcomplete/StreetComplete/blob/31a51693165996b4f79ff449f5667c36b1493bf9/app/src/main/java/de/westnordost/streetcomplete/quests/bus_stop_ref/AddBusStopRef.kt#L35-L36

Again, then you can disable the quest.

The point is you shouldn't need to. One person should be able to tag it once so they quest doesn't appear for everyone else. Someone travelling between countries shouldn't need to remember to disable and enable quests depending on where they are.

Any answer the user can give must have an equivalent tagging (Quest should not reappear to other users when solved by one)

there are plenty of quests whose applicability are context-dependent that are left to the user to decide. Plenty of areas don't post visible addresses, some countries don't have street names as part of the address, tactile traffic light indicators don't exist in my country, etc., etc..

You should really open some new issues for those things @jtracey . If tactile traffic light indicators don't exist at all (in Canada?) then the quest could be disabled there, rather than people going round tagging it as no on every traffic light.

Lee-Carre commented 3 years ago

@peternewman

Apologies for delay in replying.

which bits did you find that didn't say that[…]

You claimed that the tag was only applicable when all routes / timetables are displayed.

While yes, the key relates to display of route info, in general, the wiki didn't specify that all routes must be displayed.

Why would a stop have info about routes which don't visit that stop? That would be a lot of (irrelevant) info at each stop. A would-be passenger would need to first determine which routes are applicable to the stop.

I'll admit to having not used the bus in many countries, but I've never seen bus stops which display info about all routes in the network or by the same operator; only ones which can be accessed from that stop. Though, perhaps this is true for other modes of mass-transit.

Even in cases where a stop is part of many routes, and only the relevant ones are displayed, it's still a bit unwieldy (especially when the operator decides to add a new route, and the info board is already full, so some evident cramming occurs by whoever was delegated the task sans sufficient space or authority to add another panel). I can only imagine the hilarity of trying to post all info about all routes at every stop.

For passengers (e.g. tourists) wanting the complete timetable (of all routes), that's available by other means (website, printed copies).

Lee-Carre commented 3 years ago

Probably off-topic (forgive me?), but I hoped for some clarification.

ref:signed=no

This being distinct from “noref=yes”, since the stop may have a ref (e.g. in documentation) but it isn't displayed at the stop itself?

Mostly asking so that when using Vespucci I can add tags which would help SC (or other data-parsers). There's quite a few such transport stops in my locale.

Though, having just checked, this quest is “Never shown in Jersey”, so should probably open a new ticket for changing that.

Lee-Carre commented 3 years ago

Separately;

The point is you shouldn't need to [perpetually reconfigure software]. One person should be able to tag it once so the quest doesn't appear for everyone else. Someone travelling between countries shouldn't need to remember to disable and enable quests depending on where they are.

Having studied usability a fair bit, I can only agree most strongly.

Software is supposed to make life easier for humans, not be yet another time-sink. That, I thought, was one of the goals of SC itself; keeping things simpler for non-hardcore surveyors.

Think about why sensible defaults are important, even in highly-configurable software.

Conditional configuration, done right, is a wonderful thing; ‘auto-magic’. See, for example, the issues related to making the “Is this way lit?” quest conditional on time-of-day (i.e. only ask at night).

A usable UI displays the right info at the right time. This matches with one of SC's principles of not spamming surveyors with lots of the same quest which calls for the same answer in the vast majority of cases.

Besides also being sound technical design, think of it in terms of not wasting a surveyors time in order that they can do more actual surveying.

mnalis commented 3 years ago

Why would a stop have info about routes which don't visit that stop? That would be a lot of (irrelevant) info at each stop. A would-be passenger would need to first determine which routes are applicable to the stop.

I'll admit to having not used the bus in many countries, but I've never seen bus stops which display info about all routes in the network or by the same operator; only ones which can be accessed from that stop

It is common in Croatia, for example. While there is obviously an simplicity factor (operator can just make many copies of same map and put it on all stations), it is also actually useful when there is not direct transit to other bus/train station at that stop, but there is at a nearby stop.

Conditional configuration, done right, is a wonderful thing; ‘auto-magic’.

Just to note, auto-magic is wonderful thing, but only as long as there is a way to override it in a simple way, otherwise it becomes a source of one of the most frustrating experiences (much worse than if no automation whatsoever was implemented).

peternewman commented 3 years ago

@peternewman

Apologies for delay in replying.

My turn to apologise!

which bits did you find that didn't say that[…]

You claimed that the tag was only applicable when all routes / timetables are displayed.

Sorry, poor choice of phrasing, I meant that everything on that page, and the options, timetable/delay/realtime are all regarding the timing of the buses, rather than the display of route info.

Why would a stop have info about routes which don't visit that stop? That would be a lot of (irrelevant) info at each stop. A would-be passenger would need to first determine which routes are applicable to the stop.

On the contrary, it's very useful. TfL put posters like this on the wall of the shelters at a lot of stops so you can work out which route and stop is best at a glance, which could be a bus leaving from a different stop to the one you're standing at (there's also a separate one for night buses): https://content.tfl.gov.uk/bus-route-maps/trafalgar-square-and-charing-cross-a4-121019.pdf

Although I realise this is only really relevant in large cities with lots of services.

Though, perhaps this is true for other modes of mass-transit.

It's also true for the underground, where each carriage has a map of the central area with all the other lines and a lot of the commuter trains will show that as well as the other commuter train routes either on the train or certainly at the stations.

Even in cases where a stop is part of many routes, and only the relevant ones are displayed, it's still a bit unwieldy

TfL have had a lot of time to practise: https://en.wikipedia.org/wiki/Tube_map#History And I think got it down to a fine art relatively early on: https://tfl.gov.uk/corporate/about-tfl/culture-and-heritage/art-and-design/harry-becks-tube-map

I can only imagine the hilarity of trying to post all info about all routes at every stop. For passengers (e.g. tourists) wanting the complete timetable (of all routes), that's available by other means (website, printed copies).

Note that the bus spider maps don't show the timetable for those buses (only day/night/24/7) or indeed even info on all stops, just the important ones and the general route direction. Each stop also has more linear and simplified route diagrams and timetable info for the routes actually served from it (a bit like this): https://www.tomscott.com/vengabus/

We have underground ones too: https://www.standard.co.uk/news/transport/revealed-tfl-s-archive-of-tube-maps-over-the-last-two-decades-show-how-the-london-underground-lines-have-evolved-a3952306.html

peternewman commented 3 years ago

This being distinct from “noref=yes”, since the stop may have a ref (e.g. in documentation) but it isn't displayed at the stop itself?

That sounds plausible. I don't know for certain. The same thing is also tagged if UK post box refs aren't visible, whereas they will exist in the Royal Mail database.

Mostly asking so that when using Vespucci I can add tags which would help SC (or other data-parsers). There's quite a few such transport stops in my locale.

Though, having just checked, this quest is “Never shown in Jersey”, so should probably open a new ticket for changing that.

Ah, well if you open that ticket, you can do it within SC itself, you won't need Vespucci! :smile:

peternewman commented 3 years ago

Separately;

The point is you shouldn't need to [perpetually reconfigure software]. One person should be able to tag it once so the quest doesn't appear for everyone else. Someone travelling between countries shouldn't need to remember to disable and enable quests depending on where they are.

Having studied usability a fair bit, I can only agree most strongly.

Besides also being sound technical design, think of it in terms of not wasting a surveyors time in order that they can do more actual surveying.

More simply, the survey has been done and the result was that it's not signed, so that info should be stored until it's time to resurvey in the future.

This matches with one of SC's principles of not spamming surveyors with lots of the same quest which calls for the same answer in the vast majority of cases.

Yeah indeed, although a lot of that appears to be by suitably restricting approved quests, or disabling by location.

Conditional configuration, done right, is a wonderful thing; ‘auto-magic’.

Just to note, auto-magic is wonderful thing, but only as long as there is a way to override it in a simple way, otherwise it because a source of one of the most frustrating experiences (much worse than if no automation whatsoever was implemented).

Yeah, I think there's a difference between sane defaults and not allowing things to be changed. But separately there is no point in some quests ever being enabled in some countries (whether due to spam or not being relevant), or in some cases the communities have asked for them not to be.

peternewman commented 3 years ago

or in some cases the communities have asked for them not to be.

On which note, and why I came back to this issue, I found this just now: https://wiki.openstreetmap.org/wiki/Bus_routes_in_London#Bus_stops_legacy

"Editors originally tagged some bus stops with the routes that they served. That is no longer needed as Routes reference Bus Stops and Stop Positions directly. Editors are encouraged to delete any bus stop route tags, such as the route_ref tag or similar."

If this quest gets implemented, someone will need to check if that's still the case for London, and what the opinion is for the rest of the UK.