Suggest alternative PIS Codes #47
Labels
No Label
backend
bug
db-manager
duplicate
enhancement
help wanted
invalid
kustomize
question
user-support
web-frontend
web-user
wontfix
No Milestone
No project
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: OwlBoard/backend#47
Loading…
Reference in New Issue
Block a user
No description provided.
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Where a service is starting later in its journey than usual - during engineering works for example - alternative PIS codes should be suggested.
Eg. 1F21 starts at Warminster instead of PMH.
When a PIS search is initiated, if no valid codes are found, the backend should then search for codes which end in the stops in the search - in the correct order and without any additional stops.
If there is still no valid code found, then potentially search for codes which begin in the stops in the search.
In either case, it would be ideal for a message to flag to the user that the code is not valid A-B but will need either starting late in the journey or will need stops skipping at the end.
As an additional point, maybe where no code is found in any case - search for codes which contain additional stops that can be skipped.
The work required to implement this will not be small but will improve the user experience considerably.
Work has begun on querying partial PIS matches.
Initially, this will focus on matches which will require stops at the start being skipped. The intention is to expand this to find matches where stops at the end need skipping but probably not cases where stops at the start and end need skipping yet.
While the backend work has begun, this will also require significant re-working of the web-app to accomodate the extra information - mainly how many stops are to be skipped and at which end of the route.
The query speed will also need monitoring to ensure it meets user demand.
Backend work needs testing before any implementation can be made in the frontend.
Testing of the PIS searching functions has proven that partial matches can now be found where the journey end is identical:
For example:
The user will also be advised how many stops need skipping and from where
The plan now is to expand this for codes which require skipping stops at the end of a journey, then codes which require skipping stops in the middle of a journey.
For example:
Again, the user will be advised whether stops needs to be skipped at the start, middle or end of a journey.
One those features are complete, work can begin on making this data available when a 'search by headcode' is requested on the website.
It will be important to make it VERY clear to the user whether the displayed code is a full or a partial match.
A release (2022.2.1) has been pushed that now supports cases where you need to skip stops at the start of a journey.
Further work needs to take place for other cases.
It is also important to note that the first station isn't announced, currently we have services terminating at Bath - so the existing code for FIT, KYN, OLF, BTH can be put in a Bristol TM. Work needs to be done so that the first stop can be ignored if there is no exact match.