Navitia Bundle Laravel Package

Product Decisions This Supports

• Feature scoping for journey planning / MaaS: Informs whether to ship multimodal itinerary search, departures/arrivals boards, stop/place lookup, and disruption-aware routing by exposing Navitia’s API through Symfony services rather than building a routing engine.
• Build vs buy for routing: Supports the decision to consume a transit API (Navitia) plus thin Symfony glue instead of owning GTFS/NeTEx ingestion, graph building, and journey-planning algorithms in-house.
• Market/coverage strategy: Relevant if the roadmap targets French/European public transport coverage where Navitia-backed datasets are strong; less relevant for regions where Navitia instances are not deployed.
• Data-source and vendor decisions: Helps frame a “transit data layer” decision — self-hosted Navitia, navitia.io SaaS, or an alternative engine — and clarifies that this bundle is an integration convenience, not the routing capability itself.
• Roadmap sequencing: A low-commitment way to prototype multimodal search in an existing Symfony codebase before investing in a production-grade, internally maintained client.
• Total-cost-of-ownership assessment: With zero dependents and a low health score, it is best treated as a reference implementation or a fork candidate, not a strategic dependency.

When to Consider This Package

Consider it when:

• You are on a legacy Symfony (2/3-era) stack and already run Navitia or navitia.io, and need DI wiring and service abstractions quickly.
• You want a reference for API shape and integration patterns before writing your own typed client.
• You are in a French/European transit context with CanalTP/Navitia tooling already in the organisation.
• The work is exploratory or internal, with tolerance for unmaintained code and pinning to specific Symfony/PHP versions.

Look elsewhere when:

• You are on modern Symfony (5/6/7) or PHP 8+ and expect maintained, typed, tested integration — a direct HTTP client or first-party SDK is safer.
• You need SLAs, security patching, or vendor support; a package with no dependents and a near-zero health score is an ownership liability.
• You need non-European coverage or an engine-agnostic abstraction (e.g., OpenTripPlanner, GraphHopper, or a commercial MaaS API).
• Licensing review matters: Navitia is AGPL; confirm obligations for self-hosted/modified deployments and for the bundle itself before committing.
• Your team is not PHP/Symfony or would rather consume the API over HTTP from another service.

How to Pitch It (Stakeholders)

For executives: This is a thin Symfony integration for Navitia, a mature open-source public-transport routing engine. It could shorten time-to-market for multimodal journey planning in a Symfony product, but the package itself shows no adoption or maintenance signal, so it should be treated as a prototype/reference asset rather than a production dependency. The strategic value is in the Navitia capability, not this bundle.

For engineering: Use it to accelerate an integration spike — study its service contracts and DI wiring, then wrap any dependency behind an internal adapter so the routing provider can be swapped. Budget for a fork or replacement client if the spike graduates to the roadmap, and pin Symfony/PHP versions explicitly. Validate licence obligations (AGPL for Navitia) and confirm data coverage for target regions before committing.