Releases: vingerha/gtfs2
Remove direction_id condition from rt trips
0.4.0.3 Update gtfs_rt_helper.py
Attempt to fix realtime in local stops
0.4.0.2 Fix issues in local stop realtime
Fix bugs in local stops
Breaking change
Due to the new setup of local stop, these need to be reconfigured from scratch.
ONLY for local stops
Changes
- local stops are now sorted under 1 service
- bug resolved: tomorrow departures were shown for today
- bug resolved: grouping per stop incorrect when multiple local stops were involved
Fix schedule over midnight & add German translation
Changes
- Fix to have the proper date for stop-times that pass midnight (in case 'include tomorrow'), fixes issue #36
- German translation added, thanks @sourceforge807
- Adding an option to extract real-time data in readable format which can help identifying if the source is providing correct data, see servicecall documentation
- Rewording configuration / setup screen on trains, addresses #25
Contributors
Assets 2
Extend options for using (x_)api_key in realtime
Breaking Change
If your current setup includes real-time data collecting using a (x_)api_key, you need to redo it
Changes
Added option to select header OR query string for applying the (x_)api_key, fixes #21
Fix issue for 'include tomorrow' showing wrong date
Changes
When in the configuration 'include tomorrow' was selected, the departure/arrival time showed tomorrow's date (with proper 'today' time), fix for #23
Fix fixing real-time vehicle tracking
Changes
Previous release reduced vehicle traking to trip_id only, this to support trip-only data sources.
The 'fix' also removed the route-id tracking and thus reduced tracking for route-based sources.
Fixed
Fix issue with vehicle location conditions
Service call update: add option to exclude feed_info.txt
Changes
Add option to the update/create Service call
Why: the content of feed_info.txt (part of many zip) needs to be complete for proper zip-to-database extracting. In quite a few cases this file is not correct, removing it before extracting to the db seems to resolve the issue.
Fix to make local stops unique
Changes: local stops are now unique
Before, the local stops could be the same for various people from the same location, not only generating 'unique' errors but also making it imposisble to show them in maps per device_tracker
New: local stop "name" and "unique_id" now include the device_tracker_id for which they are setup
Added: searching routes in the static setup can now be done by typing. It makes use of fuzzy-search, which it easier to find the route in large lists. i.e. a route "001: 653 - TestrouteName - AABBCC" can now be found by typing 00 OR 653 OR TestRout OR ...etc.
"Breaking" change
you need to re-setup the local stop devices to apply this functionality