then the rest.
as I see line_ref, direction_ref and new organisation_ref more as filters, then should come with something like --line_ref="xxx". This is not working with ArgumentParser as I see it.
So I suggest that ALL is accepted for non-filtering..
What I wondered. All ValidDayBits consist only of 1. Never there is a 0 in the ValidDayBits. Is this correct (would have occured before).
Then checked with 2024-07-01: I got a result none the less, even when it is not part of the From/To.
=> something wrong with processing of operating day too
Missing data
Things I miss in the siri file
DatedTimetableversionFrame:
LineNote = Line/Name
PublishedLineName
DirectionName
OperatorRef = Line/OperatorRef
ProductCategoryRef if exists
DatedVehicleJourney
xxx Line/TransportMode
DestinationRef not done in GTFS -> NeTEx (will create issue about that next).
DestinationName not doen in GTFS -> NeTEx (will create issue about that next).
order of arguments
origin loperating_day output
then the rest. as I see line_ref, direction_ref and new organisation_ref more as filters, then should come with something like --line_ref="xxx". This is not working with ArgumentParser as I see it. So I suggest that ALL is accepted for non-filtering..
No filtering I used
I got an export with 6877 VehicleJoruneyRef which strangely is exactly the number of ServiceJourney in the original NeTEx
So LineRef/DirectionRef was not applied correctlyy and the resulting file is wrong
`Checking with non existing dates
`I checked for LineRef=BB:Line:2946291119 and DayTypeRef=BB:DayType:1002320289 with BB:UicOperatingPeriod:1002320289
What I wondered. All ValidDayBits consist only of 1. Never there is a 0 in the ValidDayBits. Is this correct (would have occured before).
Then checked with 2024-07-01: I got a result none the less, even when it is not part of the From/To. => something wrong with processing of operating day too
Missing data
Things I miss in the siri file
DatedTimetableversionFrame:
DatedVehicleJourney
DatedCalls
Some might not be possible with blablacar