Suggest alternative PIS Codes #47

Open
opened 2023-10-02 22:08:54 +01:00 by fred.boniface · 4 comments

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.

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.
fred.boniface added the
enhancement
web-frontend
backend
labels 2023-10-02 22:08:55 +01:00
Author
Owner

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.

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.
Author
Owner

Backend work needs testing before any implementation can be made in the frontend.

Backend work needs testing before any implementation can be made in the frontend.
fred.boniface added this to the Feb 2023 Release milestone 2023-11-09 14:40:24 +00:00
Author
Owner

Testing of the PIS searching functions has proven that partial matches can now be found where the journey end is identical:

For example:

Service calling at: BOA, TRO, WSB
Would return a partial match for example a code matching: BRI, BTH, BOA, TRO, WSB

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:

Service calling at: BRI, BOA, TRO, WSB
Should return code valid for: BRI, BTH, BOA, TRO, WSB

AND

Service calling at: BRI, BTH, BOA, TRO
Should return code valid for: BRI, BTH, BOA, TRO, WSB

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.

Testing of the PIS searching functions has proven that partial matches can now be found where the journey end is identical: For example: ``` Service calling at: BOA, TRO, WSB Would return a partial match for example a code matching: BRI, BTH, BOA, TRO, WSB ``` 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: ``` Service calling at: BRI, BOA, TRO, WSB Should return code valid for: BRI, BTH, BOA, TRO, WSB AND Service calling at: BRI, BTH, BOA, TRO Should return code valid for: BRI, BTH, BOA, TRO, WSB ``` 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.
Author
Owner

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.

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.
Sign in to join this conversation.
No description provided.