feat: expose GTFS data and add OpenAPI docs#65
Open
Felipequesada21 wants to merge 19 commits into
Open
Conversation
Agrega manejo defensivo mínimo en los endpoints personalizados del API para evitar errores 500 cuando faltan datos relacionados. Cambios principales: - En NextTripView, se valida la existencia de la parada usando filter().exists() para evitar errores por múltiples feeds. - Se maneja el caso donde no existe un feed GTFS activo, devolviendo 503 Service Unavailable en vez de romper el endpoint. - Se agregan validaciones para evitar errores cuando faltan trip, route, vehicle_position, position_point o geo_shape en datos realtime incompletos. - En NextStopView, se maneja la ausencia de mensajes GTFS Realtime y se devuelve una lista vacía en lugar de provocar un error. - En RouteStopView, se maneja la ausencia de feed activo y se evita fallar cuando una parada asociada no existe o no tiene coordenadas. Este commit no modifica serializers, urls, modelos, paginación ni documentación OpenAPI. Solo mejora la robustez de los endpoints custom existentes.
fabianabarca
requested changes
May 25, 2026
fabianabarca
left a comment
Member
There was a problem hiding this comment.
New feature request
- A new
api/transit-systemsendpoint to show the results of theTransitSystemmodel insidefeed/models.py - Implementation of filtering by request parameters for all endpoints by
/?transit_system=<code>so that the results are filtered, for example:/api/routes/?transit_system=MBTAor/api/routes/?transit_system=bUCR. We will handle several transit systems and thus we need to filter appropriately. - Note: the field
TransitSystem.codedoes not exist yet, it has to be created (gotta be careful with the migrations). feed_publisherinsidehttp://localhost:28000/api/feeds/should be a hyperlink (check the serializer)- Check
http://localhost:28000/api/feed-publishers/because it didn't work on my machine
As instructed by @fabianabarca
Contributor
Author
Contributor
Author
|
feed_publisher inside http://localhost:28000/api/feeds/ as a hyperlink per request
|
Contributor
Author
Adds optional `?transit_system=<code>` filtering to the 5 GTFS
Realtime endpoints:
/api/feed-messages/ publisher__transit_system__code
/api/trip-updates/ feed_message__publisher__transit_system__code
/api/stop-time-updates/ trip_update__feed_message__publisher__transit_system__code
/api/vehicle-positions/ feed_message__publisher__transit_system__code
/api/service-alerts/ feed_message__publisher__transit_system__code Existing `filterset_fields` are preserved as `Meta.fields` in the
new FilterSet classes; behaviour without the new parameter is
the same as before
Member
{
"relative_position": 0.7532,
"congestion_level": "RUNNING_SMOOTHLY",
"occupancy_status": "EMPTY",
"adherence_status": "ON_TIME",
}This will, most likely, be delivered to clients via WebSockets every time there is an update in any of the fields, but we need replication in the API.
|
Adds two new URL namespaces that reuse the existing GTFS Schedule and
GTFS Realtime ViewSets/APIViews without touching the legacy /api/
routes:
/schedule/ 13 Schedule endpoints (agencies, stops, routes, trips,
stop-times, calendars, calendar-dates, shapes,
geo-shapes, geo-stops, fare-attributes, fare-rules,
feed-info)
/realtime/ 5 Realtime endpoints + 3 custom APIViews
(feed-messages, trip-updates, stop-time-updates,
vehicle-positions, service-alerts, next-trips,
next-stops, route-stops)
Each new registration uses an explicit, prefixed `basename=` so URL
names don't collide with the legacy router. HyperlinkedRelatedField
in serializers continues to resolve to /api/... URLs (conservative
default); deprecation of /api/ will be handled in a later commit.
The metadata endpoints (transit-systems, feed-publishers, feeds,
info-services) intentionally stay only under /api/ in this commit;
they can be exposed under the new namespaces in a follow-up.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.



Summary
This branch improves the Infobús API by exposing GTFS Schedule, GTFS Realtime, and existing custom endpoints through read-only REST endpoints.
It also adds automatically generated OpenAPI documentation using
drf-spectacular, while keeping the existing manual YAML documentation in parallel for now to avoid breaking historical documentation routes.Main changes
Read-only API
ViewSets toReadOnlyModelViewSet.filterset_fields.GTFS Schedule endpoints
The following GTFS Schedule entities are now exposed:
/api/agencies//api/stops//api/geo-stops//api/routes//api/trips//api/stop-times//api/calendars//api/calendar-dates//api/shapes//api/geo-shapes//api/fare-attributes//api/fare-rules//api/feed-info//api/feed-publishers//api/feeds//api/info-services/GTFS Realtime endpoints
The following GTFS Realtime entities are now exposed:
/api/feed-messages//api/trip-updates//api/stop-time-updates//api/vehicle-positions//api/service-alerts//api/feeds/endpointAdded
/api/feeds/to expose imported GTFS feed snapshots and allow the frontend to identify the active feed:GET /api/feeds/GET /api/feeds/?is_current=trueGET /api/feeds/{feed_id}/Custom endpoints
The following custom endpoints were preserved and improved:
/api/next-trips//api/next-stops//api/route-stops/Included changes:
VehiclePositionfield names inNextTripView.StopTimeUpdate.feed_messagefilter to usetrip_update__feed_message.print()calls.500errors when data such as the active feed, realtime data, vehicle positions, shapes, or related stops are missing.OpenAPI documentation
Configured
drf-spectacularto generate automatic OpenAPI documentation:/api/docs/schema-auto//api/docs/auto/Added
@extend_schemadecorators to:NextTripViewNextStopViewRouteStopViewFor now,
/api/docs/and/api/docs/schema/still point to the existing manual YAML documentation to avoid breaking historical routes.Validation performed
python manage.py checkpython manage.py spectacular --validatecurlchecks against main endpoints./api/docs/auto/.Known pending items
backend/api/infobus.ymlstill coexists with the automatic documentation. We still need to decide whether/api/docs/should officially be replaced by/api/docs/auto/.ServiceAlertSerializerstill declares afeedfield that does not exist directly on theAlertmodel; the model usesfeed_message. This should be fixed before loading real alert data.stop_pointandposition_pointstill generatedrf-spectacularwarnings because they are PostGIS geometry fields. We still need to decide whether they should be explicitly documented/serialized asGeometryField.Weather,Social,RouteStop,TripTime, orTripDurationshould be exposed.Risk
Low. The API remains read-only, and this PR does not modify models, migrations, or ingestion pipelines.
Observable changes:
503 Service Unavailablewhen there is no active GTFS feed, instead of failing with500./api/next-stops/now returnsnext_stop_sequence: []when there is no realtime data./api/feeds/is now available so the frontend can query the active feed.Checklist
/api/feeds/endpoint added./api/docs/auto/.python manage.py checkexecuted.python manage.py spectacular --validateexecuted./api/docs/should be replaced by the automatic schema.