Hi all,

Today I'm announcing a new companion project to Mepo focused on
providing public transportation routing directions based on the
Mobility Database (https://database.mobilitydata.org/). The project is
named Mobroute and allows you to route between geocoordinates based on
GTFS data automatically pulled down upon use. The core of the routing
implementation is based on Dijkstra's algorithm and Mobroute provides
a nice and simple end-user CLI for usage. The project repository is
available at http://git.sr.ht/~mil/mobroute and I'll be using the Mepo
mailing list and bug tracker for now to also manage Mobroute development.
As a disclaimer, the project is currently in active development and
currently more of a proof-of-concept then something usable atleast at
the moment; so don't expect much to work yet..

---

The idea behind Mobroute could be seen as perhaps similarly to what
GoogleMaps routing does with public transit routing (e.g. to/from
geolocations and providing alternative routes & transfers); on a
local/command-line-based level, and ofcourse all while being opensource
and privacy-respecting as opposed to GoogleMaps. The ideal end-state
for Mobroute is that users will not have to specify which GTFS feed to
use but rather this will be automatically determined.

This idea of an opensource public transportation router is not unique,
however I do believe the implementation of Mobroute is. Other opensource
routers include GraphHopper, OpenTripPlanner, and Valhalla. The key and
unique differences between these other existing opensource routing
implementations are Mobroute are as follows:

1) Mobroute operates locally as a commandline rather then as a HTTP 
   client/server implementation. It support multiple output formats
   such as GeoJSON, ASCII, and Mepolang. It targets low-memory 
   usage devices such as the Pinephone. Rather then assuming a server
   running somewhere, the target usecase is mobile (and by extension desktop)
   Linux; giving users full control over calculating routes **locally**.
   This also has the benefit of providing a good userstory for offline
   usecases.

2) Mobroute incorporates pulling GTFS data directly from the
   Mobility Database and integrates a caching layer for said data. This
   frees the user of looking up and determining which GTFS files to pull
   down and makes for a more 'seamless' experience. Granular caching is
   a planned feature and the ideal end-state will be simply entering from/to
   as geocoordinates and having Mobroute automatically select the appropriate
   GTFS feed(s) from the Mobility Database. Currently a regex is used to
   match and pull the correct GTFS feed (which defaults to the NYC subway
   system).

3) Mobroute focuses **exclusively** on public transportation routing. In
   adherence with the UNIX philosophy and to keep things **simple**, Mobroute 
   aims to do one-thing-well, and that's routing based on GTFS data pulled 
   down. Mobroute is not concerned with routing cars, walking paths, or
   utilizing OSM data in its current form. The goal is to route between
   two geolocation coordinates by looking up the closest public transportation
   stops. PBF route data for walking directions *may* be added in the
   future however the core part of the project is that this is a GTFS
   router for now.

4) Mobroute's implementation aims to be simple.. presenting a new and
   relatively small codebase (1.5K LOC currently) written in Golang. The 
   core of the router is based on Dijkstra's algorithm. The project aims
   for simplicity and targets end-users, this is a commandline and the
   caching & routing algorithm needs to be small & comprehensible by
   users and developers alike.

So, what can be done with Mobroute today:
- Downloads & cache Mobility DB
- Automatically download appropriate GTFS feed based on regex match
- Create routes using Dijkstra's algorithm (including transfers)
  - Output format as Mepolang supported
  - Output format as ASCII table supported
- Can show nearby stops
- Can show nearby stoptimes

This is all very much a work-in-progress, but dogfooding and building
routes is working for me (testing using NYC subway GTFS), and things
have been done with a small amount of code (in comparison with the
larger routers which are based in Java and I see as relatively complex
projects). I want to keep things with Mobroute small and simple with
an end toward pragmatic usage.  In it's current form Mobroute is more
of a proof-of-concept that GTFS routing can be done simply, quickly,
and with a small amount of code. I hope for the proof-of-concept label
to be removed overtime and for Mobroute to be soon practically
usable. See the project plan in in the docs folder for more details
surrounding planned work.

You can read more (including details on integration with Mepo) and see
demos at the project's repository:
http://git.sr.ht/~mil/mobroute

Please get in touch if you're interested in testing Mobroute on different
public transit systems available from the Mobility DB. I'll be in IRC on
#mepo for questions or feel free to discuss on the Mepo mailing list here.

Cheers,
Miles

Hi all,

To follow up on this - I am separating tracking Mobroute development into
a separate srht project, mailing list, and ticket tracker from Mepo. For
anyone who missed it, Mobroute is a new mepo-adjacent project I am working
on which is a general purpose and simple GTFS / public transportation
router with automatic feed import. Splitting the project out from Mepo
should allow things in the two projects, Mepo & Mobroute, to remain
separate as these efforts, while having some overlap / integration work,
are independent of one another.

The new project, associated mailing list, and ticket tracker can be found at:
- http://sr.ht/~mil/mobroute
- https://lists.sr.ht/~mil/mobroute-devel
- https://todo.sr.ht/~mil/mobroute-tickets

Miles