Davao Transit cannot use one generic road graph as its transit model. The current repository contains two different kinds of evidence: bus services with route references and ordered named stops, and jeepney lines whose checked-in geometry is supplemented by landmarks and separate inference experiments. The data model keeps those differences because geographic closeness does not establish a transit connection.
This is a research note about the current repository snapshot, not a city-wide survey. The shared metadata dates the static input to 2026-08-10 and marks it unreviewed. The observations below describe what the code and checked-in data represent. They do not claim that the snapshot is a complete or operator-verified description of Davao service.
Bus and jeepney are different evidence systems
The current model preserves the authority difference instead of flattening both modes into a single line table.
| Question | Bus evidence in this checkout | Jeepney evidence in this checkout | Modeling consequence |
|---|---|---|---|
| What identifies a service? | Route IDs such as R102, combined with R102:AM or R102:PM | Raw LineString features with name and color; a separate direction file uses identifiers such as J-bago-aplaya | Preserve service identity instead of treating every line as an anonymous path |
| How is direction represented? | The catalog stores separate AM and PM ordered stop arrays | The current direction file has 52 entries, all forward; the inference tool has its own outbound/inbound planning logic | Do not infer a bus reversal or a jeepney return path from geometry alone |
| What establishes a stop? | A named raw stop record placed into a catalogued ordered sequence. This is the repository's closest thing to official bus stop authority, not operator sign-off. | No equivalent official ordered stop table in the checked-in jeepney input; the inference tool uses semantic anchors and OSM places | Bus stop identity can carry topology; jeepney landmarks need a review boundary |
| What is the route geometry? | 18 current features marked source: "road-routed" | 52 checked-in LineStrings, with OSM-derived landmarks in the generated bundle; Mapbox candidates are separate | Road routing can construct bus display geometry, but it does not become transit authority |
| What is the provenance? | Raw stop snapshot, route catalog, geometry generator, bundle version and hash | Checked-in line snapshot, OSM place snapshot, landmark derivation, and separate candidate-tool records | Show which artifact supplied each claim and when it was generated |
Route identity is more than a colored line
The R102 family demonstrates why the map needs the directional reference. R102:AM lists Toril District Hall first and GE Torres (Sandawa) last. R102:PM starts at Ecoland Terminal, includes GE Torres (Sandawa), and ends at Toril District Hall. The catalog also lists shared named places such as Matina Crossing in multiple directional sequences. Those repeated names are useful evidence for a possible bus connection because the transform can attach multiple route references to one normalized stop identity.
That does not mean every nearby point is a transfer. The bus graph can use shared stop identity from the catalog. A pair of geometries that merely pass within a few metres of each other does not carry the same meaning. The distinction is why the planner and map retain routeRef, routeId, direction, and stop IDs rather than keeping only coordinates.
Jeepney ambiguity is structural
The current Bago Aplaya feature is a useful example of the difference. Its production record is a LineString with a route name and color, and its direction metadata is J-bago-aplaya: forward. The record does not provide a bus-shaped ordered list of official stops. The bundle builder can derive nearby OSM landmarks, but a landmark is not automatically a boarding point or a transfer point.
The route-inference tool makes the uncertainty visible instead of hiding it. It has 27 route specifications and two correction records. The Mahayag – Bunawan correction redirects the evidence through Cabantian, Buhangin, Bajada, and Dacudao rather than trusting the route name to choose a path. The Malabog – Roxas Ave. correction omits an unresolved TF Davao checkpoint and records why. Both are examples of provenance decisions, not proof that every route has been surveyed.
The tool also refuses to treat a single attractive candidate as self-validating. It compares route candidates using snap quality, known-route overlap, family similarity, corridor coverage, detour ratio, and backtrack quality. A candidate can remain in review or low-confidence. The current production jeepney metadata remains unreviewed, so candidate-tool status must not be rewritten as operator approval.
What this model rules out
Several convenient assumptions do not survive the evidence:
- A route family is not an undirected line. Direction is part of the service identity.
- A road-routing result is not automatically a transit route. It is generated geometry or a candidate, depending on the pipeline.
- A nearby line is not automatically a transfer. The bus model has stop identity; jeepney proximity alone is insufficient.
- A validated bundle is not live service confirmation. The current snapshot has a date and review status for a reason.
- A plausible jeepney candidate is not production geometry until the review boundary is crossed and the resulting artifact is explicitly promoted.
The practical result is a more conservative network model. It may return no connection where the evidence is weak. That is preferable to teaching the planner a transfer or route that exists only because two coordinates happened to be close.
Sources: route-catalog.json, upstream-stops.json, bus-routes.geojson, jeepney-routes.geojson, jeepney-directions.json, and the route-inference data.