Locations PoC: Difference between revisions
mNo edit summary |
|||
Line 19: | Line 19: | ||
= Security = | = Security = | ||
As this is a proof of concept a single access token has been created for use by the open community. This token needs to be included as a header within the HTTPs: | As this is a proof of concept a single access token has been created for use by the open community. This token needs to be included as a header within the HTTPs request: | ||
* Auth-Token: ea8b2166-058c-4689-a72c-dd4b9b84cb82 | * Auth-Token: ea8b2166-058c-4689-a72c-dd4b9b84cb82 |
Revision as of 15:30, 15 March 2019
The RDG Locations Proof of Concept (PoC) API brings together mutiple sources of locations data from various RDG and NR services into a single service. It allows consumers to search for codes associated to a location description or to request data asscoiated to an NLC, CRS, TIPLOC or STANOX code.
This is a Proof of Concept - it is intended to evaluate the potential usefulness of such an API and should not be incorporated into any services as it may be withdrawn, or be unavailable, at any time
API
The Locations PoC has two functions:
- A search by location name/description, to return codes associated to locations
- A lookp by NLC, CRS, TIPLOC or STANOX to returned data associated to the specified code
Access
The API is REST JSON and is available from the following endpoints. Both endpoints only accept a POST request with a simple JSON body:
- Description search
- Endpoint: https://0hvzyzu9q6.execute-api.eu-west-1.amazonaws.com/beta/locs-desc
- JSON Body: e.g. {"id" : "leeds"}
- Code search
- Endpoint: https://0hvzyzu9q6.execute-api.eu-west-1.amazonaws.com/beta/locs-js
- JSON Body: e.g. {"id" : "LDS", "type" : "C"}
Security
As this is a proof of concept a single access token has been created for use by the open community. This token needs to be included as a header within the HTTPs request:
- Auth-Token: ea8b2166-058c-4689-a72c-dd4b9b84cb82
Functions
Search by Location
https://0hvzyzu9q6.execute-api.eu-west-1.amazonaws.com/beta/locs-desc
The search by location function allows consumers to specify a string of 3 or more characters, which will then be matched against the initial characters of:
- Single word location name
- Each word of a multi-word location name
For example, if the User request is “cross” the following stations would match:
- CrossHill
- CrossKeys
- Kirby Cross
- London Kings Cross
- etc.
Where the latter two are matched by virtue of a match against a multi-word location name.
The response with contain a JSON array of objects, with each object containing the location name plus at least one of:
- NLC
- CRS
- TIPLOC
- STANOX
Note: The response is determined by unique location description as set in multiple data sources. So the same location may appear more than once if it has been spelt differently in different feeds. For example, searching for {"id":"clapham junction"} will return:
[
{"description": "CLAPHAM JUNCTION LONDON", "nlc": "5595", "crs": "CLJ", "tiploc": "CLPHMJN", "stanox": "87219"}, {"description": "CLAPHAM JUNCTION", "nlc": "5595", "crs": "CLJ", "tiploc": "CLPHMJN", "stanox": "87219"}
]
this is clearly the same location, as evidenced by the codes, but is shown twice because of the different descriptions.
National Rail Enquiries Data Feeds | |
---|---|
Data Feeds | About the Feeds • Darwin Webservice (Public) • Darwin Webservice (Staff) • Historical Service Performance • Push Port • KnowledgeBase • DTD • Locations (PoC) • Real Time Journey Planner |
LDB API | About |
LDB-SV API | About |
HSP | About |
DTD | About • Fares • Timetable |
Push Port | About • XML Schemas • Schedules • Associations • Train Status • Station Messages • Alarms • Train Order • Train Alerts • Formations • Formation loading |