search

skinkie / reference

Personal repository where I collect working examples to understand inner workings while building PyNeTExConv
GNU Affero General Public License v3.0
1 stars 1 forks source link

Operator may not be defined at Line level #134

Open skinkie opened 6 days ago

skinkie commented 6 days ago

The GTFS profile currently assumes that an OperatorRef exists at Line level, it is already capable of handling branding_ref or authority_ref instead, but it is not capable of resolving this data from a ResponsibilitySet, OperatorView (at TimetableFrame) or as an aggregate from ServiceJourney[]/OperatorRef.

A preprocessing step, as suggested in #133 may take care of this, hence if no OperatorRef is found at Line level, it should search for it.

ue71603 commented 3 days ago

We rely heavility on ResponsibilitySet so we would be happy, if the system can take care. Whether in a db_to_db or a different step, can be discussed. Or do you suggest a tool_resolve_responsibility_set.py?

skinkie commented 3 days ago

GTFS expect a relationship between Line and Operator. In some step this must be resolved. Therefore I suggested #133 to assure that the GTFS requirements are met, and not 'on the fly' calculated. It is too big of hassle to maintain, if we do it for other parts.

ue71603 commented 2 days ago

Wedo this in #133

skinkie commented 2 days ago

@ue71603 the problem with aggregating these issues is that we end up with a big issue that is not a single feature. While for a proper overview a single feature description is important. I think even for EPIP this feature is important.

ue71603 commented 2 days ago

But this still means that gtfs_db_to_db.p needs to be created? or where do you want to store it? You can also go ahead and to it either in gtfs_db_to_db.py or in one of the other scripts.

skinkie commented 2 days ago

I think this specific thing "aggregate operators to line" is a transformer. We need that transformer in GTFS and EPIP.

ue71603 commented 2 days ago

I abide to your wisdom.