-
Notifications
You must be signed in to change notification settings - Fork 15
Back end
- Autocomplete end-point for stop / route / area and combined end-point for all 3.
- Function takes a string, eg. "khoda" and returns all objects matching that string with lat-lng identifier, to be able to use to send user to OTP page with lat&lng parameter
- Get headway data to display on Route pages
- Add ability to rate headway data (also other data?)
- Add user comments to pages
- Decide what data should go into GeoRSS feeds, implement the same for stop, area, route.
- Decide what data should go into GeoJSON feeds and how they should be paginated / accessed. Make changes to current API for the same.
- Figure out how to construct URL to send lat&lng as parameters
- ...
toward our stop editing sprint, we need a custom front-end to view, query and edit stops. As a first step, we need a clean API to separate concerns. Taking Yuvi's sketch for the API [1] and Schuyler's inputs, this is what we came up with:
all calls return JSON - GeoJSON is used where appropriate.
returns route object and key 'stops' as a geojson feed
returns geoJSON for stop
edits Stop information by sending GeoJSON
returns GeoJSON FeatureCollection for stops matching q
returns list of route aliases for routes matching q
returns list of area slugs for areas matching q
returns GeoJSON feed for all stops in an area
Will try and put up some better documentation and a wiki page, although we also probably want to discuss / change things around a bit - this is really the minimum we needed to be able to implement this front-end editor app by Wednesday.
All the calls should work already, please feel free to test and let know if you encounter any issues. There are a bunch of FIXMEs in the code [2] that would be nice to get done, but what we have should work fine for now.
Have also added slugs for all items generated from their display_names.
some additional notes:
i> when we do not have geometry for a stop, the geojson returns geometry as {}
ii> MUST TODO: get stop POST and GET requests to deal with alternative names.
See https://github.com/publictransit-in/wtfimb-reboot/blob/master/design.txt
This is busroutes.in done right, but not so right that it'll never ship. It is designed with the following goals in mind:
1. Make it easy for anyone to start an instance for their own city. 2. Make the entire data *user editable*, so that minor edits are absolutely painless. 3. Have an API + several clients (web/mobile/sms), so that work does not get repeated 4. Make it easy to keep data in sync with official sources, in cases where official sources are actually provided
We've picked **GTFS** to be the standard data import/export format, and **GeoJSON** to be the API transport format.
The API provides read/write access to the data, along with routing information. People need to be logged in to make write calls to the API. The API design should be as minimal as possible, and hide all implementation details.
- POST login
In: Username/Password.
Out: An access token (valid for a day or so?) on success. Should be included with all future requests
Alternative: Cookie based logins too!
- POST logout
In: An access token
Logs out the user by invalidating the access token
- GET stop?id=$id
In: Stop ID
Out: Returns a FeatureList containing a single point that is the stop of this particular id
- GET stop?name=$name
In: Stop NameNotes on Templates
Out: Returns a FeatureList containing possibly multiple points that have a name that matches the inbuilt name
- POST stop?id=$id
In: A Point GeoJSON that should be used to populate given ID
Out: Id of stop updated
Leave Id empty to create
- GET route?id=$id
In: Route ID
Out: Returns a FeatureList containing a single point that is the stop of this particular id
- GET stop?name=$name
In: Stop Name
Out: Returns a FeatureList containing possibly multiple points that have a name that matches the inbuilt name
- POST stop?id=$id
In: A Point GeoJSON that should be used to populate given ID
Out: Id of stop updated
Leave Id empty to create
- GET/POST route?id=$id&name=$name
FeatureList of Points that are part of the given Route (identified by id or name)
- GET path?from=$from_id&$to=$to_id
FeatureList of GeometryCollections that are changeoverpoints
- GET stopsnear?lat=$lat&lon=$lon&distance=$dist&type=$type
FeatureList of Points that represent stops near the given location