Recharging point & plan revisions

[nick-knowles]

Revisions to ReCHARGING EQUIPMENT PROFIEL and RECHARGING PLAN to address VVS issues

a) Add RECHARGING STATION and RECHARGING BAY

b) Allow a VETRHICEL JOURNEY to indicate a preferred VEHICEL EQUIPMENT PROFILE / RECHARGING EQUIPMENT PROFILE

c) ALlow RECHARGING EQUIPMENT PROFILE to state which VEHICLE RECHARGING EQUIPMENTs it ios compatible to
to state

[duexw]

I am generally OK with the new elements RechargingStation and RechargingBay - many thanks. By re-using the ParkingGroup, we inherit many elements and properties which apply to commercial car parking, but not to recharging public buses. That may be confusing to implementers. they will have to apply some common sense here.

The "VDV" example needs some adjustment

1. In VDV, the charging point would not be part of the ServiceJourneyPattern - otherwise you would need different ServiceJourneyPatterns depending on whether you actually recharge on a journey or not. VDV just needs the assignment from the scheduled stop point to the recharging bays which could be used from there. This is obviously possible:
   
   so that's fine in the model, but not in the example.

2. Minor issue:
   In the XML example, the ValueSet/values/TypeOfPlug is a copy of TypeOf Point. But PlugType "Bus Stop" is confusing
   I can help with fixing the VDV example if necessary.

[Aurige]

Update of the VDV Example needed (assign recharging point to Scheduled stop point)
@duexw to propose an update example, and confirm that we can update the document.

[Aurige]

@duexw requirement: Link RechargingStep to 1 Block ?

[Ulf9]

Nick has added support for charging cars at dedicated recharging bays, but these bays are related to the general parking concept, implying that the public can recharge their Teslas etc. at these recharging bays.
The added recharging bays and recharging stations seems fine. But for public use...

The actual VDV need is something else. VDV indicates that they need to model support for opportunity-charging during the time a bus in operation is exchanging passengers at a stop.

They wish to indicate that a certain physical bus stop ( that reads Quay in NeTEx) has an overhead pantograph and also to which recharging station the pantograph is linked.

So forget about recharging bay, which is irrelevant in this case. I also suggest linking the physical Vehicle Recharging-Equipment to the Quay it is serving.

In the example file create a Quay for each relevant physical bus stop. Thus one Quay per VDV - Scheduled Stop Point. Then assign that Quay to the Scheduled Stop Point. This can easliy be automated as nothing hinders using aligned Ids for Quay, Scheduled Stop Point and Passenger Stop Assignment.

Here is the extended StopPlace:

And the additional stop assignment:

And a simplified recharging point assignment:

[duexw]

Ulf, I understand your criticism of using the parkingbay element. However, from a VDV452 / VDV462 perspective, we would not like to use the Quay element and we need the RechargingStation element. I agree on the use of VehicleChargingEquipment though. Could we not just have the VehicleChargingEquipments below RechargingStation, like so:

Then we can assign the ScheduledStopPoint elements to the VehicleChargingEquipments without using Quay and without using Parkingbay:

The RechargingStation Element does not need to be below "parkings", it could also have an own enclosing element "rechargingStations"