Proposal:Validity of Route Relations
| Validity of Route Relations | |
|---|---|
| Proposal status: | Abandoned (inactive) |
| Proposed by: | Nakaner |
| Tagging: | timetable:valid_until=* |
| Applies to: | relation |
| Definition: | the period of the timetable a public transport route is based on |
| Statistics: |
|
| Draft started: | 2017-09-10 |
| RFC start: | 2017-10-12 |
Proposal
This proposal introduces the a new keys timetable:valid_until=* for public transport route relations (route=train/light_rail/tram/bus/trolleybus/ferry/aerialway). It indicates the end of the period of the timetable the route is based on. The value is a date whose format is YYYY-MM-DD.
If mappers add or modify a route relation they can indicate when the next check is necessary (usually when the next annual timetable is published). Data users are able to determine if a route relation at OSM is still maintained or stale.
What this proposal does not want to
This proposal is no replacement for any tagging scheme for temporary features. Don't use timetable:valid_until=* to map routes which where served in history (e.g. last year), will exist in future or are only served for a short time (e.g. detours due to construction works).
If you find a route relation whose timetable:valid_until=* is a date in the past, it is not right to delete it immediately. You should not delete data just because its "expiry" date passed. The same unwritten rules which apply for tags like check_date=*, also apply here.
Rationale
When public transport agencies publish new timetables, mappers want to mark which route relations have been updated yet and which not. Because large parts of Europe change their timetable on the second Saturday/Sunday in June and December every year, it is difficult to update all route relations at the day when a new timetable becomes valid. In addition, manpower is limited and some route relations are already outdated. Data consumers should be able to distinguish old and new, outdated and up-to-date route relations. The last_modified timestamp provided by the OSM API cannot serve this job because splitting one member way creates a new version of the route. That happens quite often.
Tags like last_checked=* and check_date=* are suboptimal because you usually know the end of the period of the current timetable when you add or modify a route.
valid_from=* is already in use but it is used for protected areas. That's why I avoided to use valid_until=*.
I did not choose end_date=YYYY-MM-DD because that tag would imply that the service on the given public transport line will end YYYY-MM-DD but that's wrong. timetable:valid_until=* is intended as an expiry tag (i.e. you don't have to check this OSM object until YYYY-MM-DD.
This proposal does not propose a tag for the first day of validity of the timetable because OSM is not a project to collect historic data. This means that the start date is ideally a date before today and not necessary.
Examples
If you add or modify a train route and the current timetable is valid until 2018-12-09, you should add timetable:valid_until=2018-12-09.
Tagging
see above
Applies to
This proposal applies route relations of public transport routes. It applies to all tagging schemes.
Rendering
This is a tagging proposal and no rendering proposal.
Features/Pages affected
Following pages and even more could/should be modified if this proposal passes voting:
External discussions
- The idea of such a tag was raised on "OSM-Samstag" (OSM Saturday) at FOSSGIS conference 2017 in Passau, Germany, see FOSSGIS 2017/OSM-Events/ÖPNV-Mapping for notes in German.
- discussion on mailing list Tagging
- discussion on mailing list Talk-transit
- discussion on Tagging mailing list Nahverkehr (German)
- discussion on German OSM forum
Comments
Please comment on the discussion page or on of the mailing lists listed above or the German OSM forum.