Stops view feature

[DIDONAX]

fixes #1011

[traines-source]

why is that necessary?

[DIDONAX]

the msvc release workflow kept failing because of some "path not found" error, this seemed to fix it.

[traines-source]

ah ok sry, missed the commit msg. Mmh weird that this wasn't an issue before. We should be sure that the result of the transpile is the same though

[felixguendling]

I don't think we should throw random fixes if nobody understands what's happening. Please don't change code if you don't understand it.

My theory is that the debug runner and release runner both write into the same pnpm directory locally. The solution would probably be better separation of the runners (different users for example).

[traines-source]

Some general thoughts:

• I think we agree that it's difficult to find a level of detail that fits all use cases (and I know some people are in favor of a slider :). But I still think that in our UI, we should switch from important (train) stations to bus stations to individual stops/masts/poles solely based on zoom level – and the current implementation with the transport types and grouping has convinced me even more, because I feel that it definitely goes in the right direction. I would try to do the transitions so that in most cases the shown stops are sufficiently far apart so that one can click/tap on them (meaning, I think, switching to details a bit later than right now, because the stops view is more crowded than the trips view in general – cf screenshot). If we can't agree on the stepping and we absolutely need a button (slider?), we need to find another solution for the button, because the current arrangement next to the trips toggle is confusing without any explanation (was already confusing before with just the trips toggle). – I think at least on mobile, if not everywhere, the stops should be shown by default (or always).
• I'm wondering whether for the API it would fit better if one could actually explicitly filter for stop types (transport type and pole/bay vs station group), and move the zoom logic to the UI. This would allow other clients to use the API more flexibly without needing to reverse engineer zoom levels – but is less consistent with the trips API.
• I think we should somehow visually distinguish station types. Maybe make train station dots larger? Maybe color stations according to their most important transport type? Maybe both?
• Initially, the stops layer seems to be above the labels layer (city names etc) – when also enabling trips, it moves behind the labels layer as intended?
• For station groups (particularly train+bus station groups), we need to set the position of the group to the most important substation. It is weird if the dot for a train station is on the corresponding bus station. (This is an issue predating this PR and should probably be fixed already in adr (?) outside of this PR.)

Thoughts are welcome :)

[DIDONAX]

• I agree that we should add the ability to choose which stops to return based on their type and let the client handle the rest, i think in general our api should be designed around the general use case rather than the needs of our specific UI. I also think that consistency shouldn't be an issue since i feel like placing too much emphasis on strict consistency across endpoints may lead to unnecessary coupling.
• i don't think that the stops should always be shown. personally i think its too much too look at (especially if we add coloring and have railviz enabled). I don't see the benefit of removing the disable option, but keeping it wouldn't cause any harm.

[traines-source]

Data quality is too bad, cf screenshot, or Crailsheim has a lot of train stations – maybe this indicates that we shouldn't distinguish in a too fine-grained manner and limit ourselves to the radius/size to distinguish larger (hopefully train) from smaller (bus) stations? Not sure.
I end up agreeing that we might need a stop toggle or make the stop dots less prominent – more as if they would be embedded directly into the tiles. The only thing I know is that I still don't like the arrangement of the two toggles next to each other without any explanation. But I haven't come up with a solution so far. Anyone any ideas?

I agree that we should add the ability to choose which stops to return based on their type

Ok, I guess then you can rework the API in that direction.

[traines-source]

Re Toggles, maybe a single button with a to-be-found icon that opens a dropdown/popup similar to the propositions from #1139.

I.e. with options like

Vehicles
o Realtime Delay
o Line Color
o Transport Mode
o None

Stops
o Stations
o Platforms/Bays
o None

(And later, if we promote the line shape feature from a debug button to a user-facing functionality:
Lines
o Geometrical
o ...
o None
)

It's a bit overwhelming. I think we at least need good defaults. On mobile this would be stations for me. Maybe even on desktop if we manage to properly filter long distance train stations for the Europe overview on api.transitous.org – which at least currently is not the case for at least France. So maybe we stick with Realtime Delay on Desktop for the time being.

[Lach-anonym]

Personally I like the design used in the Transportia app

And filtering for railviz and stops per transport means is also a good idea

[felixguendling]

why review if CI is red?

[DIDONAX]

why review if CI is red?

my bad i reverted some changes that broke the ci after i signaled for review.

[traines-source]

(When we keep the hover: When in place_idx_t mode, we shouldn't show platform numbers in the popups.)
Hadn't we found a consensus that we remove the stop toggle button and do it solely based on zoom? Or do I misremember? (of course I personally tend towards the dropdown in the meanwhile, but...) I think the detail level based on zoom is really good already now. Maybe OTHER/ODM should be ranked lower, around Schwäbisch Hall the bus stops suddenly turn up very early.