Attributions in GTFS

[LeoFrachet]

Hi GTFS community!

Some data producers told us they'd like to provide attribution of the data, and that the existing fields feed_publisher_url and agency_name weren't enough, because other stakeholders were implied... and were asking to be given credit.

Given the broad variety of such stakeholders (French "Autorité Organisatrice", German "Verbund", the SF Bay Area MTC which is "planning, financing and coordinating", aggregators like Danish Rejseplannen...), we ended up drafting a proposal allowing any kind of attribution (aka free text).

The draft is here: GTFS-Attributions bit.ly/gtfs-attributions

Since this question was closely knitted with the question of translation in GTFS, we also drafted a proposal for translations in GTFS. It is inspired of the Google's one, but stricter and improved.

The draft is there: GTFS-Translations bit.ly/gtfs-translations

As usual, I'm posting it as Issues to gather your impressions, and if we get closer to a consensus I'll move it as proposal.

Thanks!
Leo

[LeoFrachet]

Based on community feedback, I've updated the GTFS-Attributions bit.ly/gtfs-attributions proposal to remove the bit-encoded values and to replace them by distinct fields.

[abyrd]

I definitely agree that we shouldn't have positional bit fields in GTFS. Multiple boolean fields makes more sense. However the granularity of the permissions seems somewhat arbitrary. Why is there one field for "network data (files agency.txt, routes.txt and entities with location_type=0 in stops.txt)", but one completely separate field for attribution of feed_info.txt? Might it make more sense to allow the name of any txt file as a column name, so routes, agency, feed_info, etc. are the columns, with 1s in the columns where the attribution applies? It also seems convenient to have some way to specify that attribution applies to the whole contents of the feed without having to exhaustively enable attribution on each file. I imagine a common use case will be a single attribution record applying to the entire feed.

[LeoFrachet]

@abyrd, you're suggesting two things.

1) Remove the category, and just allow to specify table names (and field names?)

My intention was to make it both simpler (by grouping fields and files). Allowing only file name wouldn't cover some edge cases like, for example, enhancing a dataset by adding pathways information in stops.txt (which doesn't affect the stops themselves, only the other entities in the file).

It would also be the first time that the field name are "dynamic", but I can see the value in it.

2) Adding a specific field to specify "applies on the whole dataset"

Yes, we can do that.

I'll update the proposal to offer those options.

[LeoFrachet]

Proposal updated with the option that @abyrd offered. I'm unconvinced this is better, since it's not really offering a finer granularity (for example you still cannot say that you've improved the lat/lon of the stop with OSM, but only them, and therefore only them are ODBL), but it does increase the number of columns, and the cumbersomeness of the proposal (Would anybody ever put an attribution on calendar_dates without wanting to put it on calendars?)

Going all the way toward that direction would be to allow every attribution to be applied to a set of table and fields, either by allowing columns with fields, like stops.stop_name or by splitting the file in two, one attributions.txt defining those attributions, and another called something like attributions_relationships.txt with fields attribution_id, table_name and field_name. Doable if worth it.

@aababilov, @dbabramov?

[timMillet]

A PR for GTFS-Attributions (core only) has been done. It only includes attributions.txt.

[timMillet]

The PR for GTFS-Attributions (core only) has been adopted.

From the GTFS-Attributions(full proposal):

• attributions.txt is now adopted.
• attribution_scopes.txt is still being discussed.

If anyone is interested in attribution_scopes.txt within GTFS-Attributions(full proposal), please contact me!