Minimap ideas

[Vladki]

Hello, I find quite problematic to use the minimap, because stops are red in many modes, and vehicles yellow. Thus they interfere with other information, e.g vehicles vs. congestion, wear, weight or speed limit. And stops interfere with commuting, visiting, pass. destination, etc.
Also the terrain color on empty tiles makes it less usable.

I think of two solutions, depend on how hard to implement they are:

1. do not use colors from the green-yellow-orange-red scale for anything else that what the currently selected button has to show. I.e. use blueish colors for vehicles and stops, grayscale for terrain.

2. a separate button to show/hide vehicles and stops,
3. button to hide terrain - make it just light gray or something. Maybe even a button to hide buildings to show the terrain in the city as well.

[jamespetts]

I have not looked in detail at the minimap code, so I am not sure how easy or difficult that these things would be to implement. I should imagine that (2) would be the easiest, and probably the most consistent with the way in which the rest of the minimap works (enabling/disabling layers).

[Vladki]

Interesting... I thought that changing the colors would be easiest...

[Mariculous]

I have no idea what is easyer but 2. should be the prefered solution if it is not much more complicated to implement.
Further, landscape should only be colored if explicitly enabled by a new "terrain heights" highlight layer. Otherwise it should always be grayscale.

[Vladki]

Wow, nice. One more button pretty please to hide the red stations (and show the underlying way color, or building grey).
Thank you very much.

[Mariculous]

Great!
Given, it's that that easy to implement, we might discuss some imho very useful minimap reworks:
I'm not quite sure if checkboxes are the way to go here as it's some kind of a map layer and map layers usually use these button like "checkboxes" instead of actual checkboxes.
These buttons could need some reorganisation anyway.

0. Add a station layer (0 as it was already mentioned now)
When that layer is disabled, stations will not be displayed at all.
Stations itself can be the destination of a commuting journey, so these should be painted in "potential destination grey" (same as city buildings and attractions)
It might need some further fixing to get the "Destinations" layer working properly with stations, I don't know.

1. Add a "way" layer
Currently, ways are always displayed. When placed on ground, this is not an issue but tunnels under and bridges over buildings will hide these buildings on the minimap. Adding an own disableable layer or ways would allow us to hide these ways.

2. Object filters
We already have dropdowns to filter the displayed transport network by player, cargo type and waytype.
A checkbox to apply these to any objects on the map would be nice.
Especially filtering displayed ways by owner or waytype would be very useful. Filtering by cargo does only make sense for stations, maybe also for vehicles, so it should not a high priority to make it work but for consistency, it should be done if it's not too much work.

3. Additional "cargo" types in the cargo type filter dropdown
An additional cargo type for each passenger and mail class would also be very useful when filtering lines.
It is quite important to know where passengers of a given clas can travel, so when selecting "medium" passenger class, it should display all lines (and objects if 2. is implemented) that can be used by "medium" class passngers, that is "very low", "low" and "medium" .

4. Improve the coverage layers
Passengers and mail coverage layer does not seem to be quite useful. I don't know if it's a bug or a feature but the displayed information feels quite useless.
Maybe the green-to-red scale should be used to display the distance to the next (served) stop.
Stops that are not served at all should not be considered at all. Currently those don't show a coverage area but they also disturb other coverage areas.
Also, the filter dropdowns should affect this layer, especially interessting when used in combination with passenger or mail class filters.

[Vladki]

Freight coverage is not really needed. There are not so many industries, so you can check them directly. Also you usually build cargo stations so that they cover the required industry. But mail and passengers would be nice. IMHO it would be enough to show the lowest walking time stored in tiles (even if the stop is not operated). That should be quite simple to do.

[Vladki]

Great. This is what I had in mind. A nice bonus would be to show only stops of the player selected in the network selector, but this is 1000x better than anything. Also stops on city roads are essentially public so this is sufficient for me. Thank you very much.

[Mariculous]

A nice bonus would be to show only stops of the player selected in the network selector

Applying the three filters to the display of layers is generally desirable (point 2) on my idea list.
However, it will suffer from the same cut out coverage issues as mail/passenger coverage does, so I am not quite sure how useful it would be without fixing that issue.

The current layer looks well. If possible, coverage should only be displayed at tiles that are actually buildings accepting or generating passengers/mail. That way, it would be easyer to see where buildings are badly covered. Usually one does not care if earthworms on a plain green meadow live within the catchment area of a bus stop.

And I'm wondering why passenger and mail are showing the coverage but why freight is not coverage. 

I'm wondering the same tbh. It would be nice to have a cargo coverage layer for consistency, thus less player confusion, but as mentioned it's not a quite useful thing.

[Mariculous]

I think this is pretty useful

Indeed, that's a huge improvement when it comes to optimising networks to improve the use of public service.

The last thing I am missing for that kind of work now is a new stop layer that shows some kind of the potential of stops.
However, it's not too easy to define what that potential actually means.
It should be a measure for how many pasengers a stop might attract compared to other stops assuming the same quality of service.

that means, it's some kind of passenger generation and demand within catchment area but obviously, simply summing these up is quite meaningless.
E.g. When a stop is placed in the middle of nowhere with densely populated areas around the border of the catchment area the stop would calculate a high potential, although that stop is actually useless.

We could just sum up passenger generation and demand of buildings where that stop is closest to, but that is not quite meaningful either.
Imagine a stop placed quite well in a densely populated area being surrounded by other stops.
Generally, a denser placement of stops will report less potential for each stop.

Imho a good definition of stops potential would be summing up generation and demand of all buildings in the catchment area but weightening them antiproportionally to their distance. The closer the building is to the stop the higher its weight.
Something like (generation+demand)/distance might work out well.
Something like (generation+demand)/(a*distance+b) with a constant a and b could be used to adjust the weightening curve if it turns out to attract too many
where a and ba are constant adjustement factors to control how much

Maybe it even makes sense for both layers to co-exist:
If you want to link your network, you usually care about two things.
1. You don't want to drive large detours
2. You want to stop where you can attract as many passengers as possible directly, so these passengers don't need to transfer.
The antiproportinally scaled sum will give you a god guess of the latter.

On the other hand, a quite close stop distance might be worth if the area is densely populated, but not quite worth if the area is barely populated.
You might consider increasing or decreasing stop distances on a line.
The summed up passenger generation and demand will give you a good guess of how many passengers will actually use your stops, assuming surrounding stops have the same level of service.
If that number is too low, you might want to increase the stop distance to save maintainance. If the number is quite high, you might consider adding more stops.

Would it be better to integrate the "Passengers" and "Mail" buttons and switch between them using the goods category filter?

Imho, yes as it's more consistent.
On the other hand, that only makes sense if we also got cargo catchments, otherwise the filter itself is kind of inconsistent again.

n that case the button label should be something like "Station accessibility"

I would rather stay with station coverage, as station accessibility is rather about accessibility of vision-impaired people, wheelchair users and so on, at least that's my association as a non-native speaker.
Station coverage in combination with the new colors reads like "that building is perfectly covered by stops" to "that building is badly covered by stop", which is fine imho.

[Vladki]

It looks very good on the bigger map. Thank you.

It does not look that good on the small part of sparsely populated demo map. Perhaps showing stations in dark green (0 walking time) would make it look better. Also showing walking time for farm fields is not necessary. That could reduce clutter a little bit.

[Vladki]

Thanks for your efforts ranran. I think we can leave it as is.

I noticed that stations can be hidden together with buildings, so it does not matter which color they are.
Excluding fields from coverage is not worth the effort.

From my point of view ready for inclusion.

[Mariculous]

From my point of view ready for inclusion.

I agree, the coverage improvements seem to be ready.

i guess I din't meantion it before but I like the button reordering. It immediately looks much cleaner.

There are a few related things left that should at least be discussed imho.
Currently ways on the same 2d location as buildings will override building related informations on that minimap location.
Building related layers should take precedence over ways.
Additionally, or if the above is not possible, a checkbox to hide all tunnels and bridges/elevated ways would be useful.

That would be a huge improvement to all building related layers ("Coverage," "Buildings", "Destinations", "Commuting", "Visiting", "Staffing") especially in cities with an underground network.

Further, the "Destinations" layer should be grouped with the other building type layers. Currently, "Destinations" is a group on its own, thus it can be used in combination with other building related layers, which doesn't make sense and results in unreadable informations anyway.
Also, it uses an other button color.

Note that the "show buildings" checkbox and "Buildings" button might be a little confusing.
Maybe "Buildings" should be changed to something like "Population" or"Density"?
I am not quite sure of a good term to express "Population and Job Density"

I am not quite sure if a button to hide all buildings really makes sense tbh. However, as it's not disturbing I guess it's fine to stick with it.

[Mariculous]

Priority is given to bridges and tunnels, and it is not clear from that whether there are any overlapping buildings.

So mentioned alternative of a "Bridges and Tunnels" Layer might be a good compromise, so we can generally disable everything that is not on ground level.
Disabling those should be located somewhere in here https://github.com/jamespetts/simutrans-extended/blob/0a95ad37f01cf2b35656d6fe9402699af1c0c664/gui/karte.cc#L734

[Mariculous]

Currently, we get the ground to paint by using

Code Select Expand

const grund_t *gr=plan->get_boden_bei(plan->get_boden_count()-1);
I am not exactly sure how it prorises rail grounds but it seems it does.

In case of "Disable tunnels and bridges" try this code instead:

Code Select Expand

const grund_t *gr=plan->get_kartenboden();

I just did a very quick test with a railway bridge on plain greens, which worked just as expected (painted the plain greens underneath the bridge)
It might need some further tweaking here and there but using a function that returns the ground on terrain height level, seems quite straight forward to me when we want to ignore everything that is not on terrain level.

[Mariculous]

Which display/hide option is better, the whole way (but except rivers) or only the bridge and tunnel?

I guess that's hard to tell without seeing the results. Both have their pros and cons.

My first attempt would be to make a checkbox to hide all bridges and tunnels, which will allow for an overview of the ground level way network.
Building related layers should always hide ways that are at the same location as buildings and might additionally color all remaining ways in a more neutral color like black for on ground ways and some gray for ways in tunnels, as the red is a little eye-catching, thus distracting from the information we actually want to see on that layer.

In any case, I cannot imagine a use case for hiding all ways. On ground level, ways can only interfere with station buildings, signals and wayobjects.
Displaying these without the surrounding ways, however, doesn't make much sense to me.

Further, filtering ways by the waytype and player filters would be awesome.
That would require to iterate all grounds on a tile and all (actually up to 2) ways on that ground.

Something like thte following pseudo-code might work out:

Code Select Expand


/**
* @param tile the tile to render
* @param waytype the waytype to filter for
* @param player_nr the player ID to filter for
* @param show_non_ground whether to show bridges and tunnels
* @param non_ground_precedence whether non ground ways take precedence over everything on ground level
* @return the ground that should be rendered at the location of the given tile
*/
get_pixel_ground(tile, waytype, player_nr, show_non_ground, non_ground_precedence){
  gr0=plan->get_kartenboden();
  //ignore tunnels and bridges if they should explicitly never be shown or something on ground hides them whilst they don't take precedence
  if(!(show_non_ground && (non_ground_precedence || gr0->get_typ()==grund_t::boden))) return gr0;

  //iterate all ways within grounds of this tile to find the first one that matches the waytype and player filter
  for(int i=1;i < plan->get_boden_count();i++){
    gr=plan->get_boden_bei(plan->get_boden_count()-1);
    for(int i=0;i<2;i++){
      weg=gr->get_weg_nr(i);
      if(weg!=NULL && (player_nr==0 || weg->get_player_nr()==player_nr) && (waytype==waytype_t::any || weg->get_get_typ()==waytype))return gr;
    }
  }
  //if we didn't find any matching way, we draw the ground level.
  return gr0;


Later on, we can simply draw the retrieved tile the same way we currently do (i.e. applying filters and figuring out the color to draw)


Edit: starting at i=0 in the outer loop will give precedence to on ground ways over underground ways.
I chose i=1, because that's the current behavior, but I'm not sure if that behavior is desired.

[Mariculous]

I'd rather always imply building over way precedence and, instead of the "show buildings" checkbox add a "show groud level only" checkbox. I don't really see the point in hiding quite neutrally (building grey) presentated informations if there is nothing else to display on that pixel anyway.

Anyways, good job, I'd really like to see this being incorporated

One little thing that just came in mind:
Does mail (and cargo) also use the color coded coverage indicator?
For mail (and cargo) it doesn't really matter how long their distance to the mailbox is as long as it's in the catchment area.
I'd visually clearly point this out by coloring covered buildings dark green in the coverage layer when we don't show passenger coverage.

[Mariculous]

I'm kind of bumping that thread.
Could you start a pull request please? These features are really useful as they are already. Rather small changes could still be done later on.

[Mariculous]

I guess there's a misunderstanding, I didn't point it out preciesely.

When a building related layer is selected, I'd always imply buildings to take precedence over ways. Otherwise way over building precedence (as it was before)
The "show ground level only" has two purposes:
It prevents non-ground ways from hiding on ground buildings when no building related layer is selected and it will obviously clearly show what is on ground level.
Some people (like me) might be interessted in spare land on ground, in which case underground ways are disruptive.

That behavior given, it doesn't make sense to me to hide buildings as they cannot hide any information and their quite neutral color is not distracting from any displayed information. For the most part, they help orienting on the map.


About the catchment coloring, that's for sure arguable. To me it's rather confusing if there is a judgements of coverage quality displayed, if that quality doesn't matter at all. So imho any goods and mail should not use the color coded coverage quality, whilst passengers should.
The "all" option should use either of these, it doesn't really matter which one, the "all" selection is not quite meaningful in that case anyway.

Is there a special reason for throwing a pull request?

Actually James can pull the changes in without a pull request but pull requests are simply the github way of handling this.
James will get notified about the pullrequest, clearly stating "these changes are ready, you can pull them in".
Further, comments can be put on pull requests pointing out eventually required changes.
There had occasionally been cases in the past where a few months after the last post an answer like "is this ready and tested, can we pull this in?" appeared.
With a pullrequest that rather had not happened.

Although it's the github way of doing this, I don't know James opinion to pullrequests.

[jamespetts]

I wonder whether I should transfer this discussion to the development forum if this is a feature waiting to be reviewed/incorporated?

[Vladki]

I wonder whether I should transfer this discussion to the development forum if this is a feature waiting to be reviewed/incorporated?

I think so. This looks like mostly finished.

[jamespetts]

Thank you very much for this. I have spent some time looking at this this afternoon, since the existing minimap can be hard to use given the large number of conflicting colours.

This is a great improvement, and I agree that it is ready to be integrated, so I have done so. It should be available from to-morrow's nightly build. I have also updated the help text for the minimap window to reflect this and some earlier changes in the minimap window.

One thing that we may want to consider is reversing the scale in some cases, since it seems unintiutive to have, for example, green showing slow speed limits and red showing high speed limits. For commuting, visiting and mail delivery success, this is already done and explained in the revised help text, although I wonder whether there might be a clearer way of doing this.

Thank you very much for this excellent usability imrovement.

[Mariculous]

since it seems unintiutive to have, for example, green showing slow speed limits and red showing high speed limits

The other way round would be just as unintuitive tbh.
I guess, the problem is, that there are two different, often conflicting meanings associated to the color scale currently.
The natural one being green: good, red: bad.
The other one being green: few (or min), red: much (or max), as described in minimaps "show map scale" explanation.

As an example, where these harmoise well is when few is actually good and much is actually bad like congestion.
Frew congestion is green, that means, it's all right, there is no delay. Much congestion is red, that means, it's very bad, you might want to take action.

On the other hand, there are layers where much is prefered, in which case the color scale is confusing as the two different points of view on the color scale are conflicting.
That's for example, as you've mentioned, speed or weight limits, or even worse the commuting/visiting/staffing or building density layers.
Without reading and understanding the description, their meaning is absolutely unclear.
In these cases much is good, but much will be red, which is naturally associated with bad, but it would be bad if there were only few, which is green, so associated with good *zig-zag-arrow* (the forum doesn't like that utf-8 char -.-)

As you was wondering about a way to do it better, I cannot imagine of any that's using greeen to red scale due to the natural associations with these colors and the above described conflict.
If we really wanted to change that, it might require a lot of experimentation with different scales, like a colorfulnes or brightnes scale.

[Vladki]

Perhaps the scale should change labels accordingly. Otherwise I'm for the good/bad scale.
E.g. mail delivery - the map is all red, clicking on random houses, mail delivery rate i 0%. OK. (Although the mail coverage of world is close to 100%, so this may be some other error).
Commuters - map is all green, houses report commuting success close to 100 %
Visitors - green to yellow - OK
Track wear - new track green, old track red, OK
Track speed - slow track green, fast track red, ... no I'd put it the other way round.
Weight limit - higher = red.... I'm not really sure about this one... But I think it should be low = red, with mothballed ways being black, or deep red.

Also not sure about attractions - bigger ones are red. (and bigger circle). Also other circular layers for stations. I'm not sure what is denoted by the size of circle - it seems to be mostly redundant with color. If so I would prefer them to be more like the industries layer - just as big as the station/attraction itself

Attractions layer - they should include monuments layer (and perhaps town halls and headquarters too). Cathedrals are monuments, and thus not shown.

Depots - Probably just special colors for each waytype, like for industries? Having color coded cost of depot, is not useful information.

[jamespetts]

Thank you all for your comments. I think that we do want if at all possible a red = bad, green = good scale. Where this is inconsistent with min/max, probably the best way to handle this is to swap the "min" and "max" labels on the scale. Just changing the tooltip/help text description is perhaps somewhat of a hack and is not an ideal solution. One might change the min/max text to various things such as "high" and "low" depending on the context.

As for speed and weight limits, may I suggest that the colour scale be based on the speed relative to the best way(s) currently available? If they be scaled based on current pakset data rather than an arbitrary hard-coded number, the colours will be more relevant to the current moment in the game.

Thank you again for your work on this.

[Vladki]

As for speed and weight limits, may I suggest that the colour scale be based on the speed relative to the best way(s) currently available? If they be scaled based on current pakset data rather than an arbitrary hard-coded number, the colours will be more relevant to the current moment in the game.

I was thikning about the same. IMHO the best solution would be:
- independent scale for each waytype: e.g. canals would otherwise be all red. Also same green for motorway (130 km/h) and high speed track (>300 km/h) is IMHO good, while 130 km/h railway would be yellowish.
- dynamic scale according to timescale - currently fastest available way of given waytype would be green, degraded red, mothballed black.
- and if possible scale according to really existing ways, so that each has different colour, even if their speed limits are close to each other.
- same logic should be applied to weight limits.

Currently 0% utilization is green and 100% is red. It is strange that the cut powerline is green.
Even if the color scale is reversed, is 100% utilization green, is that okay?

100% utilization should be red. Also a line with no power source should be red. So a cut powerline will be - half green (part with powerplant) and half red (part with factory/town)

[jamespetts]

I agree with Vladki regarding the speeds and weights: there should be a different scale per waytype, or else canals will always be red and runways green and everything else yellow.

I agree with Ranran's suggestion to have a disconnected power line display in a separate colour (dark purple is a good choice); once that be done, green as 0% utilisation and red as 100% would make sense (although we seem not to limit the capacity of power lines at present; that may need to change one day, but that is not a high priority).

[jamespetts]

I think degraded is status, not axis weight information. You can also check it with another button that shows the condition.
Although mothballed is displayed in red, I don't think it needs to be distinguished from the bridleway where only pedestrians can pass.

There may be something to be said for having mothballed ways in the dark purple colour, although do not worry if this would take too long to implement.

[Mariculous]

A very short feedback of this feature:
The client crashed when I opened the minimap on bridgewater, but I couldn't reproduce it. The next time I connected worked just fine.

[Vladki]

Degraded - sure - one can see it with "wear". Degraded has reduced speed limit so it would be nice to see the color appropriate for the reduced speed limit in such case.
Mothballed - speed and weight limit =0, wear = 100 % so red in all 3 maps, that should work automatically, but it would be nice to show it in some off-scale darker color.

Check on current map:
Mothballed road: wear red, speed black, weight black ... OK no change needed.
Degraded road: wear red (OK), speed & weight same color as if new. For weight it is OK, for speed not. But low priority change.

Powerlines - it should be simple demand/supplies ratio. So utilisation could be even >100% (more demand than is supplied).
Anyway a special color could be used for powerlines that have either 0 supplies or 0 demand (or both), to indicate a possible problem. I don't see any other reasonable way to indicate "disconnected". But really you have to care only about zero supplies, to avoid division by zero.

Checking the new coverage feature - looks very good, But I would add one more thing - if a building is not covered, it should be red or some special colour to attract attention. Edit - I see that it is grey if I enable show buildings... So that is usable too. Edit2: I see that stops without service are not considered in coverage which is good Edit3: this is valid only for mail. Passenger stops show coverage even without any service, perhaps walking is counted as service. So this should change...

[Mariculous]

Imho many layers suffer from actually a quite huge range of values being mappen on a small amount of colors.
Often layers are like 90% green.

We can apply the above suggestions on weights and speed limits, but still it will be an issue to properly display the usual rail speeds properly, especially in periods of transition, which is where people are usually most interessted in detecting old infrastructure to set up upgrading.
There are only 10 color steps, of which some are quite hard to distinguish without a direct comparisation.
Currently, there are a tleast railway tracks of 50 km/h, 80 km/h, 120 km/h, 130 km/h, 145 km/h, 155 km/h, 160 km/h, 200 km/h, 225 km/h, 240 km/h, 300 km/h, 320 km/h around the map on stephenson-siemens.
That's already more than what we can differ using the current scale.

So my suggestion is a minimap setting where the player can influence the mapping.
For example, a min and max setting, where all values are clamped to the color scale is applied to that range.
That means, if we want to seek out for old 155 km/h tracks, to schedule replacement, we can set the range to something like min: 150, max:160,
so 150 and less will be red, 160 and greater will be green and 155 will be yellow.

I am aware, that different types of layers use different number ranges, thus specifying the range relative to the full range, rather than in absolute numbers might be sensible.

The issue of multiple layers might remain, but I am usually really interessted in the values of one of those layers a the same time, the other layers beinfg only of secondary importance, to better relate the primarily displayed data to what is going on there.

Passenger stops show coverage even without any service, perhaps walking is counted as service.

That's not an issue of the map but an issue of stop statistics and internal transfer times.
Internal transfer times are usually smaller than actually walking the same distance, thus passengers will walk to a stop "transfer" there, to walk to another stop and that's still counted as a successful journey.

You can try it out, simply placing an entirely unserved stop in a city. It will frequently report success nevertheless.
Alternatively, have a look at stephenson-siemens. For example Cheppike Manga High street ins entirely unserved. Still there are roughly 20 passengers on average using that stop successfully.

Note, that it has an internal transfer time of 0:54, but it takes 3:42 to walk to a diagonally adjacent tile.
That one is very difficult to circumvent as it's the result of graphics scale/economic scale. Walking times are calculated to economic scale, but transfer times are related to a fixed scale, which is roughly the graphics scale.

Edit: It happened again, after switching from a local stephenson-siemens save (my default save) to bridgewater.
See the attachment. The error doesn't make sense to me, however and I still don't know how to reliably reproduce. At least I got an idea.
Should I start a bugreport on its own?

[jamespetts]

Thank you for this: now incorporated. I wonder whether the scale issue might be dealt with by replacing "min" and "max" with "best" and "worst"? What are people's views on whether that would be clearer?

[Mariculous]

What are people's views on whether that would be clearer?

It will prevent contradictory confusion, in cases where clearly much is good and few is bad, but for some parameters, it's not intuitively clear if much is good or few is good.
E.g. traffic layer. From infrastructure maintainers pont of view, it's likely goof when many vehicles use his infrastructure. From operators point of view, it might be bad, as it gets more likely to delay there.

Further, density layers issues will remain. Green is good, so should city centers be green?
I'm not sure about that. It will distract from what we actually want to point out in that layer: "Look here! There are many potential passengers that you could attract by your service!
The suburbs... Well, they exist and you should serve them... Some day. But you definitely want to start in the city center!"

Thus, in any case description will be required for some parameters.

[jamespetts]

This is a complex problem indeed. Does anyone have any suggestions as to how to overcome it?

[Vladki]

Doesn't the degraded way reflect the speeddown? I haven't looked at that part in detail. (It takes time to reproduce a degraded road ...)

Maybe it does. Look on stephenson siemens game, there is degraded road (514,26) and degraded railway (623,15). But I;m not sure what was their original speed and color. (and they are green as low speed is green). So maybe we can consider this as solved.

Regarding the display of min/good vs max/bad label thing, I don't know what to do. We can view them at the same time as described above.

Maybe just change the label to: good/bad, or more explanatory (good, fast, cheap, unused, low density, new,... vs. bad, slow, expensive, overloaded, high density, old,...)

You can see a short passenger bar when you build a new station, but you cannot see mail's one. That is the reason why coverage is not displayed without mail service. (Might passengers be involved in walking on foot?)

I think it is the walking people. You can see them in connection list - walking to nearby stop is mixed with line services.