Availabilityrequest

[trurlurl]

Changes for issue #196.

@herlitze Could you please have a look at the proposed changes?
In particular the two questions (marked TODO) regarding the ticket and bookable services information in the response (do we already want to return such information, similar attributes as Trias or different ones?).

I'll then finalize the proposal according to your feedback

[skinkie]

Does this structure align with EPIAP?

[trurlurl]

Bookable services from TRIAS align very poorly with EPIAP.
What I've found in EPIAP/NeTEx:

• The possibilty or obligation of reservations is only mentioned for: wheelchairs, bicycles
• Capacities - in a vehicle - are limited to: WheelchairPlaceCapacity, PushchairCapacity, SpecialPlaceCapacity
• Additionally, we have: PushchairsAllowed, cyclesAllowed, cyclesAllowedWithReservation

[ue71603]

André: More in TRIAS than in EPIAP. EPIAP only wheelchairs and bicycles. More details there.

[ue71603]

Stefan: some times only capacity and sometimes more: why?
André: inconsistent
Malte: I could clear them up.
Stefan: Do we want to go beyond EPIAP, if we can't do it in EPIAP.
Christophe: What not a more general version type+number.
Decision: More general BookableServiceItem with Type (see new Siri mechanism Counting mechanism in FacilityMonitoring)
Proceed: Matthias includes, example,André takes a look (supply and capacity), Malte checks, then update

[ue71603]

MonitoredCountingStructure in siri_facility-v2.0.xsd

[AndreasAtSBB]

It's OK.
I didn't verify for completeness of the "BookableServiceInformationStructure", but added elements seam to be correct.

[herlitze]

I compared the TRIAS Availability Request (https://github.com/VDVde/TRIAS/tree/Version1.4).

The differences I noticed in the Request were the EstimatedTimeLow/High vs. EarliestDepartureTime/LatestArrivalTime and the missing BookableTicketAndServiceInformationGroup in the Response. Are these changes intentional?

[trurlurl]

@herlitze Regarding your two questions above:

EstimatedTimeLow/High vs. EarliestDepartureTime/LatestArrivalTime -> Yes, this was intentional - reusing the already existing EstimatedTimeLow/High which, as far as I could judge, can do the job.

BookableTicketAndServiceInformationGroup -> I don't understand your question about this group missing - for me it is part of the response, see line 218. Could you tell me more precisely what you think the problem is?

[herlitze]

@herlitze Regarding your two questions above:

EstimatedTimeLow/High vs. EarliestDepartureTime/LatestArrivalTime -> Yes, this was intentional - reusing the already existing EstimatedTimeLow/High which, as far as I could judge, can do the job.

@trurlurl The way I see it is that the EstimatedTimeBandGroup also contains 2 times and thus can technically be used, but the names of the elements and the comments do not fit in my opinion. I am for taking the element from TRIAS.

[herlitze]

@trurlurl

BookableTicketAndServiceInformationGroup -> I don't understand your question about this group missing - for me it is part of the response, see line 218. Could you tell me more precisely what you think the problem is?

I pulled the changes in the availabilityrequest-Branch, but your changes are in the branch trurlurl:availabilityrequest, which I seem to not have access to. The structure I see here in the changed files looks fine.

[trurlurl]

As discussed in the last meeting (18.10.22), I added BookableServiceItem with type and number. The type enums map to the ...Capacity elements from Trias (https://github.com/VDVde/TRIAS/blob/Version1.4/Trias_Booking.xsd).
NOTE: With the exception that I added four more items that were not in Trias: boardingAssistance, alightingAssistance, onboardAssistance, unassistedMinorAssistance.

@herlitze Replaced EstimatedTimeBandGroup with new MinMaxTimeBandGroup.

[sgrossberndt]

This is a proposed merge from @trurlurl (a real name would be nice) from a working branch in trurlurl:availabilityrequest to a working branch in VDVde:availabilityrequest.

This should simply be merged and afterwards a pull request should be created from VDVde:availabilityrequest against https://github.com/VDVde/OJP/tree/changes_for_v1.1

Only then Travis will run fixing issues and rendering the documentation, it does not run in other peoples repos currently.

[trurlurl]

Removed documentation label, all the changes are now in PR #262.