New OTP Debug UI

[t2gran]

Search Bar

The first set of controls are fixed, while the menu allow some "custom" controls to be added. In this case the Street Preferences is included. If there is not enough space to show all input controls the controls should flow over to a second (and third) line of controls and the hight of the bar should be adjusted.

Advanced controls

A control with a meny button(Transit Modes and Walk Preferences). The menu button open a "drop down/floating" input control, while the text-field display a very short summary of the values. We can create a service for parsing/serializing the summary text in OTP - so we do not have to do this in JS.

Time Input

Clear box or write now + enter/tab to insert current time. This will update both the time and date.

Itinerary List

Itinerary

We only need to show the graphical "time-line". De vil si vi kan droppe Start, End and Trip Summary.

Legs

We can skip walk/driving directions for now and list of intermediate stops.

12:00:11 - 12:56:00 Walk 3.8 km, 55m49s to Rådhuset [✓]

12:00:00 - 12:56:10[red] 12:55:00 Bus M1 Flekkerøy - Sørlandsparken, Agder Kollektivtrafikk, from Rådhuset to Vågsbygd kirke [✓]

Expanding itineraries and selecting legs

Multiple itineraries can be expanded. Each leg has a check box. When selected the itinerary and leg information is added as a line in the "Details View - Compare table"

Elevation profile

Skip for now, see Details View.

Details View

Show details for selected elements in the itinerary list.

Compare Itineraries and legs

Show selected itineraries in the same order they are in the list.

Elevation profile

I would start without the elevation profile. I think we should show it in the Details View , not in the list.

Formats

Time: 23:00:01[+/-1d] Seconds are only shown if not zero, offset days are only shown if not zero and relative to search date.
Cost: $ 200 000
Reluctance: 1.2 (scalar)
Duration: 1d 2h 3m 56s Only none zero element are shown
Speed 1.33 m/s

Links

We should link to trip and stop when appropriate. We will link to the bundled graphiQL API for OTP.

[t2gran]

New OTP Debug UI Kickoff Minutes

13:00 CEST Wed 2023-08-23
Thanks to @leonardehrenfried for writing the minutes, I have copied it from Gitter to here.

General goal

Fresh development with better maintainability but not building a feature complete replacement.

What should be the features?

• Wanted
  • Map view
  • Start travel search
  • Itinerary view
  • Modify GraphQL query sent to the server, perhaps through variables
  • Debug layers
• Features to drop
  • I18N
  • Selecting map layers (can be added later)
  • Geocoder (can be added later)

Which API?

Since Entur is a major sponsor, the client will use the Transmodel API.

Technical stack

Browsers

Firefox, Chrome, Safari, Internet Explorer newest versions only

Tom-Erik is in favour of the following stack

• TypeScript
• React
• JSX
• GraphQL framework: GraphQL.JS
• Build tool: probably not going
• Map library: Leonard recommends MapLibre
• Some UI library like Bootstrap, Material Design, Tailwind. Needs to look plain and square.

Modules & deployment

Debug UI will be a separate source module.
We aim for the same user experience of the UI being available at http://localhost:8080/. Details of this we will figure out down the road.

Who does what?

• Tom-Erik will do the initial setup.
• Leonard and Thomas will join in once the setup is complete.

[leonardehrenfried]

If we agree (do we?) that we don't want to add the compiled output of frontend build into the jar somehow, then I have a suggestion for a workflow:

1. Client is developed locally and code submitted for review
2. PR is merged
   • CI compiles frontend application
   • Gives compiled output an auto-incremented version (like a datetime, just like we do with the docker images)
   • Deploys the artifacts to a CDN (like NPM, Github Pages...)
3. A post-merge step (we already have some) checks if there is a new version of the frontend code, automatically updates the version that OTP uses and commits it to the repo.

[testower]

@leonardehrenfried Yes, as a general outline, and without going into the details, I think that's a good idea.

[optionsome]

Should we cache the settings in the local storage/session storage and have some reset button available?

[t2gran]

Minutes review meeting - 2023-11-16

• Move search bar up on the same "line" as logo. Expand logo with serverInfo: {serverInfo {version otpSerializationVersionId buildConfigVersion routerConfigVersion gitCommit gitBranch } }
• Keep itineraries expanded when another is opened. This is important to be able to compare itineraries.
• Filtering for list of itineraries (not now)
• Open entities in GraphiQL, query on id, show name - user will need to add other fields to the GraphiQL query in the GraphiQL client.
• No copeling between access/egress input control
• Fire route request every time the start/end flas are moved in the map. Fire first search when both markers is set.
• From/to should support Quay/StopPlace id as well as coordinates. It should be possible to type in both coordinates and ids.
• No need to support a geocoder (maybe later).
• It should be possible to see if RT data exist or not, even when the RT is onTime. For example: 12:00:11 (On time)
• It should be possible to open the route search in GraphiQL. In the first version we will only support linking to the OTP builtin GraphiQL client, but we might want to be able to configure this (base url/dialect). This is can be done by adding a button next to the Route button.
• Make the DetailsView to an overlay on top of the map .

[testower]

I suggest we keep this issue open even after we merge #5334, until we are ready to replace the old client.

[testower]

I will probably look at the following tasks in the near future:

• Keep itineraries expanded when another is opened. This is important to be able to compare itineraries.
• Open entities in GraphiQL, query on id, show name - user will need to add other fields to the GraphiQL query in the GraphiQL client.
• From/to should support Quay/StopPlace id as well as coordinates. It should be possible to type in both coordinates and ids.
• It should be possible to open the route search in GraphiQL. In the first version we will only support linking to the OTP builtin GraphiQL client, but we might want to be able to configure this (base url/dialect). This is can be done by adding a button next to the Route button.

@leonardehrenfried will take the lead on CDN deployment with help from me, as well as improving on the map

[leonardehrenfried]

Yesterday I worked on the CDN deployment. Sneak peek: https://github.com/opentripplanner/OpenTripPlanner/actions/runs/7228613899/job/19698335048

[leonardehrenfried]

https://github.com/opentripplanner/debug-client-assets/commits/main/

[leonardehrenfried]

My next task is to build vector debug layers. Here is a sneak peek of a simple stop layer:

[github-actions]

This issue is stale because it has been open 90 days with no activity. Remove stale label or comment or this will be closed in 30 days

[andtry]

Whishlist from internal meeting at Entur 05.08.2024

This list consolidate todoes in this issue with newly identified and tries to list them in a prioritized order from Enturs perspective:

• 1. It should be possible to open the route search in GraphiQL. In the first version we will only support linking to the OTP built in GraphiQL client, but we might want to be able to configure this (base url/dialect). This is can be done by adding a button next to the Route button.

• 2. Open entities in GraphiQL, query on id, show name - user will need to add other fields to the GraphiQL query in the GraphiQL client.

• 3. Add edge permissions on edge-layer with different colors, similar to the old client

• 4. Add aerial photo map layer (Norwegian specific and bing/google)

• 5. From/to should support Quay/StopPlace id as well as coordinates. It should be possible to type in both coordinates and ids.

• 6. Keep itineraries expanded when another is opened. This is important to be able to compare itineraries.

• 7. UX - Group input parameter (eg. time, modes, to/from, div)

• 8. UX - Less line spacing on expanded legs to make it easier to compare two itineraries.

• 9. Additional metadata on areastop (name, type)

• 10. Additional map layers (bike safety, wheelchair access, elevation)

other points that needs elaboration:

• Filtering for list of itineraries (not now)
• No need to support a geocoder (maybe later)
• Make the DetailsView to an overlay on top of the map .