Proposal talk:Unify departure boards
Semantics and accessibility
While I like the idea to unify both tags (and appreciate the effort!), the proposal doesn't capture the accessibility issues of passenger information. In its current use, it wrongly associates auditory-relevant information with the presence of a physical board-formed display - while visual, auditory and tactile passenger information can co-exist independently at the same place. In reality, there is no hierarchy between the different perception modes.
As this tag is especially relevant for accessibility (btw: we are currently implementing this tag in a branch of Wheelmap, and want to help blind people to find out more about transit places), it should be designed with accessibility in mind from the start.
In essence, both "…display" and "…board" imply a specific kind of passenger information. I'd propose to change the base name to passenger_info=* to capture all kinds of passenger information, and split the differences in a secondary tag part to accommodate for the different kinds of senses that a passenger information entails, e.g. passenger_info=visual`, passenger_info=auditory, passenger_info=tactile, passenger_info:visual=* … like the values of sensory=*.
To get inspired what extensions might come up in the future, maybe have a look at the A11yJSON format for describing physical accessibility Media format / PerceptionMode / ActionMode
--Hypo808 (talk) 12:54, 10 December 2024 (UTC)
About compound values for timetables and electronic displays
I like the proposal. For clarity, we might want to explicitely mention that some public transport stops may have printed timetables and an electronic display showing real-time information, hence anyone parsing this key should also care for tags like departures_board=realtime;timetable. Bxl-forever (talk) 23:37, 30 November 2024 (UTC)
- This was proposed by last Proposal:Refine_departures_board_tagging
Problem is at least departures_board=realtime;interval doesn't make it clear in whether it's showing only printed frequency/headway, or the real-time display is (only) a countdown without exact time. That's why the rejected proposal wanted to separate them.
—— Kovposch (talk) 09:26, 1 December 2024 (UTC)
Arrival boards
I don't have any strong opinions on which tag to pick, but departures_board=* does mean we'll need a new key for electronic arrival boards, which are arguably more important to map over here in Belgium since there's typically only one in the whole station, if even that. —M!dgard (talk) 08:33, 1 December 2024 (UTC)
- At first, this feels a funny question. Perhaps departures_board=* serves both purposes in most other cases, and can be used for both. But arrivals could be useful in airports as well.
—— Kovposch (talk) 09:31, 1 December 2024 (UTC)
Well, first of all, this proposal mainly focuses on trains/busses/trams and not airports, as this is also what either tag is currently used for. Also, this tag only is an attribute (to be used in combination on a bus/train/... stop) not a standalone feature to indicate the exact position of the board. I don't flight very often, but I think in airports one can relatively safely assume, to have arrival/departure times present in general, and it would be useful how many and where exactly the boards are located. Heliassus (talk) 10:45, 1 December 2024 (UTC)
- Right, I had overlooked that it's only an attribute. For micromapping stations and airports a way to map the locations themselves would be cool indeed. —M!dgard (talk) 22:35, 24 December 2024 (UTC)
For the original question regarding arrival boards, I don't know the exact situation in Belgium, but here in Germany the time between arrival and departure is usually basically the same for busses and most trains, or at least any board showing the arrival times also shows the departure times. So I would go with Kovposch in saying that departures_board serves this purpose. Heliassus (talk) 10:45, 1 December 2024 (UTC)
- In head stations you can't deduce arrivals from departures at all. Other stations also often have some trains that have their terminus there. And local trains often wait for 10 minutes or more in a station. If you're waiting for someone at the station, an arrivals board can be useful. —M!dgard (talk) 22:35, 24 December 2024 (UTC)
PIDS has other pontential uses
A passenger_information_display=* could show other info. It's overlapping with printed schedule boards.
- Delay extent and details for lines and even the entire system, not only individual trains
- List out all stops by the trains, and train class
- The furthest station that the earlier departing all-stops class will reach first before the later departing limited-stop class
- The stations where different train classes exchange passengers
- Boarding position on platform
- Train car classes
- Train, or train car crowdedness
Until those are decided, there's not really a need to touch passenger_infromation_display=* . Only departures_board=delay needs to be renamed.
—— Kovposch (talk) 09:37, 1 December 2024 (UTC)
This may have been the original intention and the literal meaning, but to what extent is this reflected in the minds of the mappers? Most mappers I have seen are unaware of the difference in meaning between them and the wiki page only talks about live times as well. Furthermore, while a PIDS could show all of the different things you mentioned, there's no way to specifically tag them with the passenger_information_diplay key, as it only allows for yes/no values. So if you see a station with passenger_information_display=yes the only information you can reliably expect to be present are the realtime times, as they are the most common. Heliassus (talk) 10:34, 1 December 2024 (UTC)
Passenger Information Boards carry a lot more than departures, such as Special Timetable operates of Christmas/New Year Period, check your journey times or Take care as there is a risk of ice. --Trigpoint (talk) 12:04, 1 December 2024 (UTC)
Yes, but this diversity is in not taggable with the passenger_information_display key as it only allows for "yes" or "no". So a bus stop/train station/etc. with passenger_information_display=yes doesn't tell you anything specific about what is displayed there. The only thing you know for (relatively) sure, is that realtime information is displayed, because that's the only thing common among all PIDs. That's what I wanted to say with my previous reply, sorry if it's been unclear. Heliassus (talk) 13:16, 1 December 2024 (UTC)
If it's really wanted, one could go ahead and define a tagging scheme for all the additional information a PID could convey under the passenger_information_display or a similar key (maybe even a subkey of departures_board) and make a separate proposal for this. I personally would have little interest in specifying or tagging them, but there might be enough interest from other mappers. But the current passenger_information_display key badly serves this purpose, because it doesn't allow any further specification than yes or no. Just the information that there is a PID showing SOMETHING isn't really helpful at all (especially as currently it can mean only the realtime departures).
In my (and others) opinion, the departure times (and whether they are realtime or static) is the most important. So that's what this proposal is about.
Or to put it briefly: PIDs can display more than just departure times, but the key is neither used uniformly for this purpose at the moment, nor is it even possible to meaningfully do so in its current form. Heliassus (talk) 13:37, 1 December 2024 (UTC)