Minor patch release to bump android version code to (8).
This release improves overall documentation and correlates with the
release of Mobroute v0.9.0 which brings some performance improvements
and improved GTFS updating capabilities. See below for a detailed list
of changes in this release:
1. Improved Documentation
The documentation for Transito has been improved in several aspects. The
userguide now explains routing parameters information, advanced
configuration parameters, and information on updating feeds. And,
additionally the development guide has been updated. A new documentation
website for the larger Mobroute project is available and Transito's
documentation is published within this site, see below links for more
details:
- Transito Documentation: https://mr.lrdu.org/transito
- Transito Userguide: https://mr.lrdu.org/transito/doc/doc_transito_userguide/
2. Ability to Load GTFS Data Directly from Agency URLs
Prior to this release, by default loading any given GTFS feed would
utilize the Mobility Data's mirrored GTFS archive URLs for the given
feed indiscriminately. This is problematic in certain scenarios as there
can often be a delay between *when* the Mobility Database updates feeds
mirrored GTFS data and *when* new GTFS feed data becomes available at the
source for any given agency. As such, in updating to Mobroute v0.9.0,
there is newly added functionality to allow pulling from *either* the
agency's server GTFS URL directly *or* using the Mobility Database CI
cloud bucket URLs (default). The new advanced configuration param in
Transito named 'Use Agency GTFS URLs' now allows you to toggle between
these two functionalities. Note: after changing this param you should
update or re-add the feed to get the associated GTFS data.
3. Removal of Direct Dependency on Mobsql
A long standing piece of technical debt has been that Transito depended on
both Mobroute & Mobsql directly. In this update, the *direct* dependency
on Mobsql has been removed and Transito now only depends on Mobroute. This
was a long term maintainability issue which is now resolved thanks to
updates in Mobroute v0.9.0 which passes through feedsearch abilities
and thus only Mobroute and not Mobsql is depended on as of this release.
4. Other Updates via Mobroute v0.9.0: Performance, Bugfixes, etc.
In addition to (2) and (3), the update to Mobroute v0.9.0 brings a
few other small but relevant updates to note including:
- GTFS downloads now handle being interrupted correctly and quitting the
application in the middle of fetching GTFS data will no longer result
in a corrupted zip error message (temporary downloaded GTFS ZIPs will
just be disregarded and a new download will occur on next update).
- GTFS ZIP archives are always redownloaded now and caching systems are
ignored for GTFS *updates* thus ensuring the latest data always.
- Performance on routing has been improved for the final connection
IDs extraction & formatting process by using SQLite OIDs rather then
manually created UIDs.
5. Duplicate Favorites Bugfix & Cleanups (thanks @Hugo Osvaldo Barrera)
A bug (#108) which involved favorites being duplicated when adding new
favorite stops has been resolved thanks to Hugo Osvaldo Barrera. Thank
you for this contribution Hugo.
6. Schema Updates
A few small schema updates have been applied for naming & code structure
consistency. It's recommended to clear your database & cache (`rm -r
~/.cache/mobroute`) before updating from v0.8.* to v0.9.0. And then on
first launch manually update any prior added feeds (or alternatively
wipe added feeds config via `rm -r ~/.config/transito`). Apologies for
the manual user-intervention; long-term I am considering investing in
a more standard SQL migration process.
Minor patch release with several changes including:
- Improves perf when routing in separate geographic regions
- Switch departure schedules back to be enabled by default
- Fixes bug preventing computation of crossfeed transfers
- Fixes cache label in feed search
- Note: Android Version Code 7 correlates with Git Tag v0.8.4
Minor patch release to address a few small issues:
- Fixes perf issues with stops tab listing; adds needed indexes
- Fixes perf issues with schedules on stops tab; adds needed indexes
- Clarify in runtime init error DB schema changed; guide users to clear cache
- Note: Android Version Code 6 correlates with Git Tag v0.8.3
Minor patch release to fix a few bugs:
- Resolves issue with crossfeed transfers & doubling up added GTFS feed IDs
- Shows error in selectlist if stops fail to load on stops tab
- Fixes issue with data-ingest where H:MM:SS timestamps handled incorrectly
- Note: Android Version Code 5 correlates with Git Tag v0.8.2
This is a minor patch release just to address making the departure
schedules feature disabled by default due to perf issues. Users who
wish to enable departure schedules can still do so by using the advanced
config checkbox.
This release of Transito adds the ability to view logs, adds daterange
metadata for loaded GTFS archives, refactors the GTFS load feed render
logic, and has vastly improved load performance via updating dependencies
of Mobsql/Mobroute to 0.8. The embedded Mobility Database CSV was updated
/ snapshotted on 2024/11/01. Note for Android builds this v0.8.0 tag
release correlates to Android version code 3. See below for a detailed
list of major changes:
1. Show Logs During Load and While Routing
Both while loading/computing GTFS feeds and also while routing, a
new button has been added to the UI allowing the user to 'Show/Hide
Logs'. This button uses the newly added customizable logging abilities
of Mobroute/Mobsql and allows the user to see the Mobroute/Mobsql logs
while a long running task in progress. This provides a great deal of
transparency into *exactly what* is happening behind the scenes and
should help debug slow processes further. Previously for certain GTFS
feeds in the ticket tracker it was reported that generally 'Compute'
was slow or 'Routing' was slow in particular scenarios; which is helpful
and replicable with GTFS feed ID / routing request information. However,
debugging & reporting can now be taken a step further in that users can
see the precise step of the load, compute, or routing process creating an
issue. And users are now encouraged to add this information with timing
in the case something takes too long.
The 'Show/Hide Log' toggle button is now shown in the following places:
(a) Upon loading/computing newly added/updated GTFS feeds on the load screen
(b) While a route calculation is in progress on the route result area
(c) After a route calculation has failed on the route result area
(d) After a route calculation has succeeded on the route debug result subtab
2. Daterange Metadata Added for Loaded GTFS Archives
Daterange metadata (e.g. the day range of available GTFS data per
earliest and latest referenced dates in both calendar & calendar_dates)
has been added to the 'Manage GTFS Feeds' section of the config tab. A
common problem with routing is that a user may inadvertently add a feed
that was deprecated or is inactive (yet not yet marked as inactive by
the Mobility Database). In this case, routing will always defacto fail,
however it previously wouldn't be so clear as to why.
By adding daterange metadata, it should make it more clear to the enduser
whether a loaded feed is 'valid' for routing and for which timespan. Also
this metadata can help notify to users to when they should update their
GTFS data per the app's built-in update functionality.
3. Internal Render Logic for GTFS Load Refactored to be a Tab
The logic which is responsible for rendering the load/compute GTFS UX has
been reworked internally. While this is primarily an internal change,
users will notice in the load UX, 'Load' is now shown as a tab at the
top of the screen. Internally the 'Load' tab render logic is organized /
was refactored to be a tab/page itself that is automatically hide/shown
automatically (so it's a 'virtual' tab in a way). This provides a good
amount of code clarity and removed some technical debt that was introduced
in the refactor to a incorporate a separate GTFS load cycle in 0.7.
4. Performance and Other Improvements via Mobroute/Mobsql 0.8
The dependencies for Mobroute/Mobsql were updated to 0.8 bringing vast
performance improvements for GTFS load/compute times. Liberally end-users
should see around 2-3x performance improvement of the overall GTFS
load/compute cycle and in some cases potentially even higher improvements.
See the release notes for Mobroute/Mobsql 0.8 for details on performance
improvements.
5. Internal DB Schema Changed: Users Should Clear Storage/Cache if Upgrading
The storage and cache directories should be cleared before upgrading
as the internal database schema has been updated. On Linux you can run:
`rm -rf ~/.cache/mobroute` and on Android within system preferences please
select clear/storage cache in system app preferences after updating.
This release of Transito was focused on further polishing the overall
UX to be more approachable to end users. To that end, the GTFS loading
UX has been reworked, the overall tabs UX has been reworked, there
is a new stops selection tab, and several smaller changes have been
applied. The embeded Mobilty Database CSV was updated / snapshotted on
2024/09/13. Note for Android builds this v0.7.0 tag release correlates
to Android version code 2. See below for a detailed list of major changes:
1. Addition of Separate GTFS Feed Load & Update UX
The UX for initial loading of GTFS feeds has been reworked such that upon
adding a new feed on the Config tab, the GTFS feed is immediately fetched
and loaded rather then being 'lazily' loading upon the first submitted
route request. While GTFS feeds are loaded, the UI is now blocked and
shows an elapsed timer for progress & a spinner. This UX should make it
more clear that GTFS load is a one-time process. In addition to this new
UX for loading GTFS feeds on the Config tab, now each feed also may be
updated (per latest GTFS data) on the Config tab in a UX which functions
similarly to initial GTFS load.
2. Tabs UX Rework (Several Changes)
A number of changes were made to how the tabs UX of the app functions.
Firstly, by default, now the user now starts on the Config tab if there
is not atleast 1 GTFS feed configured (and no other tabs are present
until a GTFS feed is added and fully loaded). This should make it more
clear to the user the 'order' of operations (in that previously the
'Search' and 'Route' tab were essentially not fully functional without
a loaded GTFS feed in anycase). Secondly, 'favorites' functionality
has now been moved from the previous Search tab to its own dedicated
'Fave' tab (only present if the user has saved >1 favorite). Thirdly,
the previous Search tab was renamed to POI. And finally, a new 'Stops'
tab was added, see next section for further details.
3. Addition of Stops Selection Tab
A new tab 'Stops' has been added which allows the user to select from
stops from all enabled GTFS feeds to route to/from or favorite. This
effectively allows Transito to be more simply used in an entirely offline
and streamlined fashion. Rather then searching for a POI to route to/from,
you can now just select stops to route to/from. This should greatly
improve the general UX and usability of the app; making it quicker to
test one-off feeds & route requests.
4. Routing Params Moved to Route Tab
The 'Advanced Configuration' parameters which previously lived on the
Config tab only effect routing and as such were moved to the Route
tab. A new 'Params' button can be used to toggle between showing and
hiding these variables as these are bit verbose.
5. Offline Mode, Departure Schedules, and Crossfeed Transfers Toggles
Three new checkbox toggles were added on the Config tab: Offline Mode,
Departure Schedules, and Crossfeed Transfers.
Firstly, Offline Mode lets you explicitly disable all 'networked'
features. Since the GTFS load UX is now separate from the route UX
this was a natural feature to add. Toggling offline mode disables the
following online features: (a) feed add UX, (b) feed update UX, (c) POI
searches. All other features (e.g. namely routing and stop selection) are
defacto offline. *Do note*, that when in offline mode; while all 'in-app'
functionality is offline, external links such as the geo:// URI links for
locations and the rendered map (via browser) do still rely on the network.
Secondly, Departure Schedules enables showing of upcoming departure
times for each stop on the Stops tab. This lets the user quickly get a
sense of activity at a given stop / station. This feature is disabled
by default as for large feeds it can be a bit intensive to fetch this
data from the DB on each selecting a given stop; but in my testing for
many feeds this works perfectly fine and performantly and this may be
enabled by default in future releases.
Finally, Crossfeed Transfers allows you to determine if when adding a
new GTFS feed whether generated transfers between the different feeds
should be calculated. Generated transfers between feeds are in general
a computationally expensive feature and as such this is disabled by
default. To use crossfeed transfers, just enable the Crossfeed Transfers
checkbox and then when routing also make sure 'Generated Transfers'
in the routing params is enabled.
This is a minor patch release that addresses issues related to some final
changes for an initial F-Droid release.
Updates:
- Fastlane metadata short_description.txt fixed to indicate app both
downloads GTFS data and then calculates routes offline.
- Fastlane metadata long_description.txt mistakenly named, renamed to
full_description.txt.
- Fastlane metadata full_description.txt updated to be a bit more
self more explanatory & include link to userguide.
- Mobility Database CSV embedded in binary & used from local FS rather
then being downloaded on boot from bit.ly mobility db link as is
default case with mobsql/mobroute.
This is a minor patch release that addresses issues related to
reproducible builds on Android / compatibility with F-Droid. The build.sh
script has been updated to not use set -x by default, args are passable
to gogio directly via the bandroid task, and the .build.yml signs the
apk for Android via gogio's -signkey / -signpass args rather then signing
separately via apksigner.