google / transit

https://gtfs.org/
Apache License 2.0
581 stars 177 forks source link

Consuming applications not incorporating changes to fields when record id is unchanged #348

Open westontrillium opened 2 years ago

westontrillium commented 2 years ago

We have noticed consuming applications incorrectly assume that a shape or stop is unchanged when its id remains the same. These applications process new stop_ids and new shape_ids, but will often ignore existing ones between datasets, even when values such as lat/lons, stop names, or codes, are changed.

It seems common sense to us to assume that a record should be able to maintain a consistent id when a new dataset is posted but still have other changes to the data (e.g., stop_name, lat/lon) incorporated. Consumers should be processing such changes regardless of whether a record has a fresh id.

We are wondering if there is either a gap in the Best Practices (http://gtfs.org/schedule/best-practices/#dataset-publishing-general-practices) or if this is an existing norm that is not being enforced/followed?

gcamp commented 2 years ago

Your interpretation is correct, I would consider that bugs in consuming applications.

Relevant past discussion : https://github.com/google/transit/pull/171. Everyone agreed that stable ids was generally going in the right direction but we need to clear up https://github.com/google/transit/issues/288 before we make it happen.

leonardehrenfried commented 2 years ago

I agree with @gcamp. A feed is only scoped by itself.

If you consume a feed you have to totally disregard the information in the previous versions.

Otherwise you'd have to change the stop id whenever you make changes to a stop's properties and this is definitely not what I want. In some countries there are national stop registers and using the same stop id in several applications and formats is extremely useful.

stevenmwhite commented 2 years ago

Also in agreement with the previous comments.

We change the data within a given entity ID all the time. If a consumer is not looking at that data simply because the ID is the same then it's definitely bad practice, and probably even more (as @gcamp said) a bug.

github-actions[bot] commented 4 months ago

This issue has been automatically marked as stale because it has not had recent activity. It may be closed manually after one month of inactivity. Thank you for your contributions.