[cli] feat: export GTFS data to database & for ingesting into directions/routing API

[danshilm]

Initially, I wanted to export the data from OSM to GTFS files and then use that to feed into the routing API. But that would require also augmenting the OSM data before I can use it in the mobile app. That also leads us to have the issue where we are essentially at the mercy of the data on OSM. Bad idea ❌

Now, the way I decided to do it is to export the data from OSM into the database in a structure that's as close to the GTFS format as possible (having it be exact would be great). Use that data to generate the GTFS files, and use those GTFS files to generate the geojson (with gtfs-to-geojson) for use in the mobile app and to feed into the routing API. The data in the database can be easily verified and will serve as the source of truth. This also allows for users to easily edit the data if necessary. And those changes can then be selectively propagated to OSM once verified (we don't want erroneous data to end up on OSM neither).

I don't like Firestore for this. It was a bad decision. Sure, out-of-the box offline support is hella nice, but moulding structured data into a NoSQL database is just asking for troubles. Sigh.. 😮‍💨 I will migrate the data to a proper SQL database (long live Supabase 🎉), but for now, the most important feature of the mobile app needs to be functional first.

GTFS files to add (reference):

• agency.txt*
  • missing individual bus operators
• stops.txt*
  • missing bus stop zones to be able to calculate fares
• routes.txt*
• trips.txt*
• stop_times.txt*
• calendar.txt
• calendar_dates.txt
• fare_attributes.txt
• fare_rules.txt
• shapes.txt
• frequencies.txt
• transfers.txt
• pathways.txt
• levels.txt
• feed_info.txt
• translations.txt
• attributions.txt

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
mobouzer	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Apr 22, 2024 7:02pm