DatedCall should really not have a DayOffset

[skinkie]

If you would create a DatedCall, I would expect that the intention is to have a date and a time, which are combined. The current model allows a Departure and Arrival structure to have a time with a DayOffset this will obviously lead to very strange ambiguities.

Can we check if this should be restricted?

[Aurige]

If I remember well the day offset on Call is necessary due to the fact that some vehicle journeys can last several days (a trans-European bus for example), and you need to know on which day of the journey you are.

[skinkie]

If I remember well the day offset on Call is necessary due to the fact that some vehicle journeys can last several days (a trans-European bus for example), and you need to know on which day of the journey you are.

On a call, sure, but we are talking about a DatedCall which has departure_date and arrival_date. So if this means we need restriction ;-) sure. But I would prefer a better object inherintance.

[nick-knowles]

Documentation could state that explicit date and time takes precedence over Offset, but Offset is still useful to have for passenger information "Next day " or "two days later" so as to make clear. people can get very confused over pms and ams

[skinkie]

Documentation could state that explicit date and time takes precedence over Offset, but Offset is still useful to have for passenger information "Next day " or "two days later" so as to make clear. people can get very confused over pms and ams

The point is that an offset is something else than an explicit date. If we now consider an offset being an attribute instead of a qualifier... it does not make sense if in an other case it is a qualifier.

[Aurige]

Deprecate DatedCall in NeTEx ? YES ! unless somebody comment here in following days ... PR to be done (@skinkie or @Aurige )

[skinkie]

@Aurige It is worse. A DatedVehicleJourneyGroup instroduces both datedPassingTimes and datedCalls. Are we sure we can remove DatedCalls? I see that the datedPassingTimes are just TargetPassingTimes, so I guess we can just make it calls.

[ue71603]

@skinkie shouldn't you reference the PR you did for this? Or is this still open?

[ue71603]

addressed in #596