Talk:Key:gtfs:feed
Jump to navigation
Jump to search
Deprecation of gtfs:feed=*
Deprecation of gtfs:feed=* leaves some open questions:
- requiring usage of
gtfs:gtfs-key:feed=value
adds a lot of extra work for- tagging: add the feed name to each and every GTFS key you want to tag at the object even if there is only one feed
- if you refer to a special version (release_date) of a feed, you have to add
gtfs:release_date:feed=date
as well although "release_date" is not a valid GTFS key as suggested here
- if you refer to a special version (release_date) of a feed, you have to add
- would you prefer then
gtfs:gtfs-key:feed:release_date=date
?
- would you prefer then
- coding (QA, ...) - performance: loop over every key of the object and evaluate if it matches e.g. 'gtfs:route_id:.*' instead of simply checking whether the 'gtfs:route_id' key exists. But the coding of this is a minor issue, I do care about the performance aspects.
- as mentioned, gtfs:feed=* has priority over network:guid=* and this has priority over operator:guid=*
gtfs:gtfs-key:feed=value
then must have priority over gtfs:feed=*, over network:guid=* and over operator:guid=*
gtfs:gtfs-key:feed=value
should only be used if there is more than one source of GTFS information (=feed)
- thus replacing the current usage of a colon separated list of feeds, e.g. gtfs:feed=DE-SPNV;CH-Alle and e.g. gtfs:route_id=91-T31-j24-1;91-6-O-j24-1 (just an example)
I see the need of gtfs:gtfs-key:feed=value
mostly for "stop" related objects: gtfs:stop_*:feed=value
rather than for "routes" or "trips"
We should not deprecate gtfs:feed=* but allow it as a valid tag.
We should require that gtfs:gtfs-key:feed=value
must be used if there is more than one feed.