Predicted occupation

[ue71603]

solves #398

However, currently only works for Calls

@Aurige I need guidance: How to put this into PassingTime /VDV 462 method. And also do we need for new mode a version that puts it on the Vehicle? Somewhere else?

Also folders: Should the thing be in a different folder? Should other NeTEx specific elements be incorporated?
Did I get the right "entrance" into formation?

[skinkie]

Question: is there a reason you want to use a NeTEx element, instead of reuse a SIRI element?

[ue71603]

Question: is there a reason you want to use a NeTEx element, instead of reuse a SIRI element?

@Aurige Do you want this methodically?

[Aurige]

Thanks @ue71603 ... it's a very goo starting point. We need to make a few updates for a better NeTEx integration, I will work on it ASAP (jumping from meeting to meeting right now :-( )

[ue71603]

Nick: CheckConstraint in NeTEx. Enum in NeTEx. reconsiliation. needed with simple NeTEx.
Christophe: Is at calls is natural. Occupany varies from day to day. It is different.
Nick: Journey and JourneyPart and Deck/Level needed and per date. PointInJourneyPattern would be better.
Christophe: DayType structure needed.
DayType added to VehicleOccupancy.
Like RunTime/WaitTime.
Into part Deck Plan element. right deck plan.

part2_oc_

[ue71603]

not import SIRI.

[ue71603]

• switched to part 2
• DayType added
• occupancies now also as part of TimetableFrameGroup
• occupancies added to JourneyGroup and JourneyPartGroup
• made Occupancy a first class citizen
• rebuild everything to occupancies
• updates example

[skinkie]

Can we have an example for "a call or a timetabled passing time"? Would it also be possible to have OccuptationInFrame which references a ServiceJourney.

[Aurige]

Solving some Occupancy_RelStructure and OccupancyInFrame_RelStructure (in FRAME cannot contain Refs)

[Aurige]

Sorry, I did it too quickly, the sequence was missing

[nick-knowles]

FYI This is the Transmodel model for recording historic occupancy.

[nick-knowles]

THe current proposal has several issues
a) The occupancy counts by each type are denormalised so that different categories occupancy are flattened out and explicitly enumerated , ok but less flexible / extensible than having a subelement with type of occupancy/ occupancy count subelement
b) seems to be conflating concerns (historic reporting of all occupancies for all day types vs prediction fo a specific journey)
(c) redundant and potentially conflicting by having filter values that can be in conflict with parent context by mixing in day types and other stuff that is already given by the parent context

Would be cleaner as a simple occupancy content structure (ie no filters etc) that goes on specific context eg a a call . journey part etc that already have a daytype etc (b) a standalone n occupancy container with filters etc that allows the same occupancy content to be exchanged by itself - and is closer to the UML for NetEx transmodel. Also them which Frame would the cccupancy container go in?

[Aurige]

@nick-knowles - @ue71603 - @Aurige to Update the proposal, including Transmodel update (maybe for next TM revision)

[ue71603]

have a look at https://3.basecamp.com/4847067/buckets/19640795/uploads/4409256610

[nick-knowles]

Ulf has proposed revisions to the TM Vehicle Occupancy MODEL to separate estimated from actual values

Also some renaming of elements for SPOT OCCUPANCY

[ue71603]

I think @Ulf9 @Aurige @nick-knowles you will have to do the PR changes. The new TM conform NeTEx structure is way to complex as for SBB to ever consider implementing it for Switzerland in the foreseeable future as we already have a working version: https://opentransportdata.swiss/de/dataset/occupancy-forecast-siri-dataset
And if it needs to better fit into DECK PLAN, then I am the wrong person to do it anyhow.

[Aurige]

I agree that going to the details of the DECK PLAN level is quite a lot of work, and will lead to a lack of a global overview of the occupancies. Knowing that time is flying, and that there are quite a lot of request for this information, could we stick on this implementation proposed by @ue71603 , maybe rename it "OccupancyView" and accept it (just solve the small issues in the comments) ?
I add it as a discussion point for next meeting

[skinkie]

What would this OccupancyRef mean in this context?

[skinkie]

Discussion:
Think in an OccupancyFrame which an occupancyAssignment (similar noticeAssignment).
OccupancyView might also be 'better'.