changing QuayType for "on street" bus/tram

[ue71603]

Comment from Nick:
Thanks for the image
Apologies but I am not in the EPIAP group so I have missed prior discussion - but my naive interpretation from the name having not seen the the discussion (which would be typical for others and new users) I think shows there is a problem.
So it is not "busOnStreetBoarding" boarding - as all busStops are "On street" by definition - but "busStopWithInRoadwayBoarding" ... so at the very least the name is highly misleading in that it fails to make the pertinent distinction from a normal bus stop which is also on a street - and so and will probably be wrongly used by naive users for their normal regular "pavement boarding " stops.
Are such bus stops also marked by a pole or other indicator at the side? How do passengers know the bus or tram will stop in the vicinity? If that is the case then the in road boarding aspect sounds much more like the Transmodel / NeTex model concept of a QUAY + BOARDING POSITION, attached to a STOP PLACE (rather than being a property of theSTOP PLACE itself) , and what you are describing is an additional classification of either the QUAY type (QuayType = BusStopInRoad ?) or BOARDING POSITION ( BoardingPositionType = positionInRoadwayAtBusStop ?_ ) . . Remember, for buses one typically has a single STOP PLACE representing both directions e.g. "Town Hall", with two separate QUAYs e.g. "Eastbound Town Hall" and "Westbound TownHall", representing the QUAYs ( ie poles / bus shelters) either side of the street , and if needed, one or more BOARDING POSITIONs indicating the locations for the passenger to stand to board the bus.
See the existing classifications
image.png (view on web)
By introducing a separate stop type for certain specific combinations of QUAY and BOARDING POSITION type you are arguably hacking the system - and if one starts mixing up what are meant to be orthogonal concepts you soon have a combinatorial explosion and spaghetti.
Anyway, to resolve this at the very least there need to be better comments in the XML for the enums to explain the difference between on street and on street boarding. Personally I would prefer one either renamed the stop concept to something like inRoadway boarding, or better still made it a classification of either the QUAY the BOARDING POSITION rather than the STOP PLACE, This would allow you to specify precise coordinates for the points to stand either side in the road according to direction to enter the vehicle - which presumably still applies to in street boarding
It may also be useful to stand back and ask the so what why do you want to distinguish such stops - presumably the use case is to flag stops that are not suitable for disabled access. Doesn't an accessibility assessment do this more clearly?

Clarification from my side:

• We are talking QUAY TYPE. So that is correct.
• I updated the definitions
• I depreciated the values.

[ue71603]

original discussion here: #388 (comment)

[trurlurl]

Wouldn't busStopWithinRoadwayBoarding also have to be used to describe the situation where the boarding position (where to enter the vehicle) is on the street but the waiting area may be on a Quay at the opposite side of the street (i.e., passengers wait for the bus to arrive, then cross the street to board)? If yes, then the text should be adapted.

The comment of @nick-knowles made me think about such cases and the level of detail one wants to describe Quays and Boarding Positions. I am not aware that separate modelling of waiting areas and boarding positions is foreseen. Such situations also exist (or at least used to exist) for small railway stations: one has to wait for the train to enter the station, and only then is allowed to go to the Quay where the train has stopped. Should this be modellable?

[ue71603]

Good point. And this is often the case. waiting is on the side of the street and a traffic light blocks the traffic for alighting/boarding. However, most models for classic public transport don't use BOARDING POSITION.

[ue71603]

As EPIAP is still in voting. Do you think we can change the two terms in the specification during voting and don't use depreciation? @Aurige @Joostb61 @duexw

[Joostb61]

As EPIAP is still in voting. Do you think we can change the two terms in the specification during voting and don't use depreciation? @Aurige @Joostb61 @duexw

OK for me, the old terms 'busOnStreetBoarding' and 'tramOnStreetBoarding' are not used in the Word document, so the documentation remains consistent.