Discuss how related_explorer should resolve inward objects

[skinkie]

It is obivously that if a ServiceJourney/LineRef exists, the user wants to see the Line too. The user is not interested in all other items that point to that line. Some objects in NeTEx only have inwards references such as NoticeAssignmentInFrame, the user may be interested it the NoticeAssignment towards the ServiceJourney. This would then resolve the Notice.

We cannot do a general all Ref resolving pattern, since an DataSourceRef would resolve the DataSource and thereby everything in that delivery. Discuss which special cases we must investigate, and how to find them.

[skinkie]

@ue71603 ^^^

[ue71603]

Ideas:

• Work only from a list of starter objects e.g. StopPlace, ScheduledStopPoint, VehicleJourney, Interchange, InterchangeRule etc.

• Then follow only ref that are referenced within those objects or are children

• We then also need a mechanism to only parse stuff once. (index that says "parsed" or something)

• If I start with StopPlace, I am mostly interested in Quays

• ScheduledStopPoints should give me StopPlace, Quays via PSA

• ServiceJourney should give also some stuff.

Perhaps we define this as lists?

Or you want to really go fully recursive based on ref-attributes?

[skinkie]

I would prefer to go through the recursive refs. That tree can be 'relatively easily and fast' be build based on all the previous work done. But it those things also asume that the source data should know what it was doing. Or it must fall back into a search for an id in all tables.

[ue71603]

Improvements for related_explorer.py.

• After first run through
• Add als PassengerStopAssignments where ScheduledStopPointRef is nn the processed list and expand StopPlace, Quay and BoardingPosition recursively.
• DayTypeAssignment: where DayTypeRef is in the list and process

[skinkie]

@ue71603 more examples are JourneyMeeting, InterchangeRules.