Delfiplus extensions

[ue71603]

• changes to ramp/hoist
• more information in stationMap
  removal of an element that we could not find out, what it does (replaced with a length and width)

[Aurige]

is this replaced by something else ?

[ue71603]

I think this was answered by @duexw

[Aurige]

Renaming is always a risk for backward compatibility ... On the French side, we can still accept this one since it is not used yet !

[duexw]

AccessVehicleEquipment can be either a Hoist or a Ramp, but some properties are only available for either one of them. Both change proposals have the same objective: if we replace RampBearingCapacity with just BearingCapacity, then we can use it for Hoist as well. If we replace HoistOperatingRadius by an Equipment width and length property, then we can use it for both ramp and hoist. We think the risk of change is low - in Germany no one has implemented AccessEquipments yet as well.

[ue71603]

I think this was answered by @duexw

[Aurige]

That's what I was expecting from BusStop ... needs clarification

[ue71603]

added clarification.

[Aurige]

Same as for bus.... we have already tramStop and TramPlatform .... I was expecting tramStop to be on street.

[duexw]

We refer to a situation where a bus or tram stops in the middle of the street, but there is no separate quay and/or crossing equipment. This means that passengers have to cross a lane in traffic if they want to board the vehicle. Maybe an enum name like "busOnStreetCentre" would express it more clearly.

[Aurige]

Ok, it was not obvious at first: it needs to be clarified so people won't use one instead of the other (and renamed_centerStreed_ instead of onStreet, or the OnStreetCentre you proposed )

[Joostb61]

Is the essence here that boarding and alighting the vehicle take place directly on the street? If yes, then I suggest to use "busOnStreetBoarding". "tramOnStreet" is clear. It's hard for me to imagine what this would look like for a bus. For tram there is a priority rule: when a tram stops at a "tramOnStreet", the tram may not be overtaken on the right so that passengers can get on and off safely. For busses we don't have onstreetboarding in the Netherlands.

[trurlurl]

I have seen the following situations:
Bus stops at a place where there is no platform or pedestrian lane on the right side - passengers have to cross the road (either before or after a,rrival of the bus) for boarding. (I think this is illegal in the long run, but may exist for several years.) Almost like Joost's proposal, I would call it busBoardingOnStreet

tramBoardingOnStreet - a tram stop (which may even have a narrow platform), but on the right of the stop there is a bus lane where buses and taxis (and probably bicycles) may pass. This riskier situation might be labellled tramBoardingOnStreet (unless, perhaps, if there is a road crossing nearby - then it might be considered a regular stop).

[ue71603]

changed names

[trurlurl]

See inline comments

[trurlurl]

wheelchairLift is defined for AccessFacilitySet, not for LiftEquipment
The mentioned tokens do not refer to real EQUIPMENTS like LiftEquipment, RampEquipment - this confuses me because they should be References to a TYPE OF EQUIPMENT, though perhaps that's perfectly correct...

[ue71603]

I think this should be fine. This is not a direct reference to the type, but an enum in association. Or do the others think it should be more aligned? @duexw @Aurige @skinkie
We currently don't have an example. Do we need one?

[nick-knowles]

Why do we need BusOnStreet Boarding and tramOnstreet Boarding? Is that not exactly what BusStop amd tramStop mean ?
For bus stops that are not on the street we have busBay (eg in a bus station) and busPlatform (eg a raised platform for bus, as might be shared with tram)

Maybe we should add more elaborate descriptions to make this clear

Or was something else meant by BusOnStreetBoarding e.g. no pavement or an unmarked stop . But adding separate "Stop types" for different types of on street bus stop " pollutes the categorisation. Would be better to have some further property that characterises an onstreet further bus stop. Either way it needs to be revised as at teh moment it is either misleading / redundant or both.

[ue71603]

@nick-knowles This was discussed and already answered by Wilfried. We have bus stops that are in the "middle" of the street and have no direct "border". E.g. a bicycle lane or even a street lane is between the "place" where the bus stops. Passengers will cross the lane (usually a traffic light or some special markings block the traffic during boarding/alighting. That is what is meant by this.
So it would look like this:

and this is a special case. Especially PRM wise.

[ue71603]

@nick-knowles also: This was voted on by the EPIAP group in several meetings. Therefore I am quite unwilling to do anything to change it. IN EPIAP there even is an image I think. If you have concrete improvements for the description, there I am open.

[nick-knowles]

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

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?