Feature request: optional local GTFS import for offline use

[fusion7676]

Hi Organic Maps team,

I'd like to propose an optional feature that would let users import a standard GTFS feed directly on-device for local offline use, and I'd love your guidance before starting any work.

Context and homework: I've reviewed the experimental GTFS pipeline (docs/EXPERIMENTAL_PUBLIC_TRANSPORT_SUPPORT.md -> download_gtfs.py + gtfs_converter -> generator_tool -> .mwm), the long-term vision described in #5331 / #5332 (server-collected, CDN-cacheable universal format with offline routing), and the related discussions in organicmaps/gtfs-osm-matcher#139 (installing GTFS from zip) and the comment in #5331 about "loading any specific gtfs file by needs of the user, starting with a small simple feed".

My idea is not to replace or bypass your GTFS-OSM matching pipeline or the work done via https://gtfs-osm-matcher.organicmaps.app/. It would be strictly optional and complementary, for users who already have an official GTFS feed from their transit agency that is not yet integrated centrally, or for private/regional feeds that may never be.

How this would be different from the previous requests:

• User-managed, not team-maintained: The feed lifecycle (import / update / delete / expiry) would be 100% owned by the user. No additional maintenance burden for the team to keep feeds fresh.
• Lightweight conversion, not raw zip: I understand from Implement public transport routing #5331 that GTFS zips are heavy (35GB+ globally, text-based) and not suitable to load raw on mobile. The proposal is to import the zip, convert locally to a lightweight, app-internal format (similar to what gtfs_converter does to JSON, or a local SQLite as in the Mobroute discussion), stored separately from .mwm files, with no modification of the map data itself.
• No OSM matching required for MVP: First PoC would work standalone (GTFS stops/routes only), avoiding the complex GTFS to OSM matching issue, with possible matching as a later step. This keeps visual clutter and ID-consistency concerns (mapping.txt / mapping_edges.txt) isolated from the central pipeline.
• Minimal scope to start: As suggested in Implement public transport routing #5331, I'd start with a single small and simple feed as a proof-of-concept to fix UX, performance and routing issues before considering any broader mapping of feeds to regions.

Questions for you:

1. Would such an opt-in, complementary approach fit your long-term vision, or are there architectural reasons why GTFS processing should remain strictly in the internal pipeline?
2. Are there technical constraints you see that would block this (e.g., ID stability across regions, storage, licensing, or the subway-filter logic)?
3. If the approach sounds reasonable, would you be open to a contribution in this direction? I'm personally motivated to build and maintain this long-term, I need this feature myself for daily use on my own phone, so I'm ready to dedicate consistent time to a PoC, documentation and testing, and to iterate based on your feedback.

Thanks for the incredible work on Organic Maps and for considering this. Happy to adjust the scope entirely based on your guidance.

[biodranik]

Hi and thanks for the details. Unfortunately, user-uploaded GTFS files do not scale (only expert users can manage it), and they won't provide live updates.

FYI, we've almost implemented the "long-term" solution (live schedules + routing), the missing part is client UI and testing. Some work is going on in #12890

Make sure that your country/city feed is set up in https://gtfs-osm-matcher.organicmaps.app/ and that osm stops/platforms are properly mapped/matched, and it will work in OM automagically when we finish.