Topic: 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...

[Freahk]

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.

[Ranran]

They could be easily implemented


https://github.com/Ranran-the-JuicyPork/simutrans-extended/tree/minimap-convoy-and-contour-option

[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.

[Freahk]

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.

[Ranran]

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.

It's a standard bug. I posted it before but it hasn't been fixed. This is not calculating the range from the station, but that information is recorded in tiles. Therefore, it is necessary to change it with a new method.
These don't help, as you say, because they don't display the correct information. And extended one is terrible because of wide station coverage. IMAO, I recommend removing these unless we make new ones.
And I'm wondering why passenger and mail are showing the coverage but why freight is not coverage. 

[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.

[Ranran]

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.

 



Note that we no longer display player colors.
Also we may need to change the button label and tooltip text.

[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.

[Freahk]

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.

[Ranran]

Some further changes:

Code: [Select]

filter_buttons[index].text_color = filter_buttons[index].pressed ? SYSCOL_TEXT_HIGHLIGHT : SYSCOL_TEXT;The existing code tries to change the text to white when the button is pressed, but this code is incorrect.
This is due to standard code, but has been fixed in the current standard. The color when the button is pressed is changed automatically, and only the color when the button is not pressed can be specified at initialization.
I fixed this because black text is often ugly because the color of the button gets dark when the button is pressed. On the other hand, there are a few cases where the white text is unsightly. (For example, a cream colored button.) We will need to fix this individually.

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.

Yeah it certainly didn't look well as it looked like a figure showing air pollution. (´・ω・｀)
I wondered if I could make it translucent, but it turned out to be difficult.

I'm wondering the same tbh. It would be nice to have a cargo coverage layer for consistency, thus less player confusion,

What I wanted to say was about consistency issues. I would like to solve this in conjunction with the above mentioned issue.


Check this out 


Passenger and mail coverage will only appear where the building is, as Freahk suggested.
This means "accessibility to the nearest station" of the building, and since this is building information, it is classified in blue.
You will check on the main screen whether earthworms can access the station. 

Now these tooltip texts have been tentatively entered like this. Proofreading native speakers helps. (need to check the last question first.)

Passengers	Accessibility to the nearest passenger handling station
Mail	Accessibility to the nearest mail handling station

Then "Freight" is information about "way", so I colored it in orange.
It should be noted that this is very similar information to the "Traffic" next to it. "Freight" indicates the total amount of cargo passed and "Trafic" indicates the count of vehicles passed. Therefore we may have to change "Freight" to another word.
This is language-dependent and is now shared with other dialogs so we changed the translatable words to avoid interference with changes. (Freight has been entered as the default for English.)


And rearranged the buttons by group.

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

This is a great improvement idea and it was also easy to implement.

I think this is pretty useful


And a question.
Now I have made it compatible with the station owner and the corresponding waytype filter for the station.
Would it be better to integrate the "Passengers" and "Mail" buttons and switch between them using the goods category filter?
In that case the button label should be something like "Station accessibility" (Is "Accessibility" appropriate for the English example?).
Then you will be able to check the goods network coverage, but the usability (and ease of user understanding) may be slightly worse. And, as be pointed out, the usefulness of goods network coverage indication may not be so high. How do you guys think?

[Freahk]

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.

[Ranran]

shows some kind of the potential of stops.

I suspect it will be a widespread implementation that goes beyond minimap improvements.
Specifically, 1) City growth, 2) Class statistics.

How much passenger demand there is, how many people there are, and how many traffic there are, which is a very important factor not only for stations but also for commerce.
There is also a distinction between job demand and visiting demand. It should appear as land value in the real world.
They are not enough for passenger demand alone. It should also include class information.
Creating a very low class transportation network in places where there is no very low class demand is a bad choice. But currently Simutrans-extended doesn't provide that information to the players in a straightforward way.
If convoy has multiple classes and we want to know the usage of each class, we have no choice but to observe it for a long time in a primitive way.
Therefore we cannot devise a strategy based on statistics. City stats, station stats, and convoy stats - I think they need class stats.


And the problem with displaying demand on the minimap:
In this time I was able to work on these improvements quickly because I had previously worked on a patch that added an indication of the success rate of transportation for city buildings.
At that time I also made a color mapping of the size of the demand, but since the value of most city buildings is small compared to it because the attraction building and factory sometimes have huge demand, the color mapping is useless was.
Special buildings have thousands of demands, whereas city buildings have at most 100 or so. So most of them are green as they are insignificant.

Perhaps showing stations in dark green (0 walking time) would make it look better.

It happened unintentionally. The distance to the station refers to nearby_halt_t, but the station itself does not have it, so it is not drawn.
It's not impossible, but it requires extra work. It needs to be applied filters, not just colored the station tile.
And I don't think it's a good idea because a "station" like a bus stop fills and hides a way such like a road.
I think that changing the color of the station to a color that does not conflict is one measure. For example pink or purple. (Green is used for the ground, blue is used for the sea.)

Also showing walking time for farm fields is not necessary. That could reduce clutter a little bit.

I don't know how to do that. (´・ω・｀)

"Buildings" are currently judged by the following simple divisions:

Code: [Select]

enum typ { boden = 1, wasser, fundament, tunnelboden, brueckenboden, monorailboden };I'm not Zeon's pork so I don't know exactly what they are pointing at. (´・ω・｀)

It's a bit more subdivided in building_desc_t :: btype, but there's nothing to identify a field there either. I'm not sure about the consequences of changing it. But I wonder if it's worth the effort.
If there is a simple way to distinguish fields I missed, I would appreciate it if someone could tell me.



Text that has been added or needs to be changed so far in this improvement. Proofreading by native speakers will help.

Button label

Code: [Select]

Stop coverage
Show contour
Show buildings
map_btn_freight

Tooltip texts

Code: [Select]

Show the distance to the nearest station
Color-coded according to ground / sea level altitude
Displays buildings in gray and stations in red

Show convoys

Thank you. (´・ω・｀)


EDIT:
I forgot to report, but the buttons in Passenger and Mail have been merged.
The button of "Convoys" has been changed to green, which allows multiple simultaneous display.

[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.

[Freahk]

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.

[Ranran]

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.

I agree. I fixed it.

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 also agree with this. I changed the button label to map_btn_building_level. Because "Buildings" is also used in the City information dialog.
For English translation, I tentatively entered Density suggested by Freahk. Please translate into the correct words by the native speaker of each language.
The actual content of this mapping is the internal level of the building object. Land prices, building height, renovation, etc. are related.

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.

I agree with that opinion, but I don't think this change is easy.

As mentioned earlier, the base 2D map is colored with these simple distinctions.

Code: [Select]

enum typ { boden = 1, wasser, fundament, tunnelboden, brueckenboden, monorailboden };The corresponding code is below:
https://github.com/jamespetts/simutrans-extended/blob/0a95ad37f01cf2b35656d6fe9402699af1c0c664/gui/karte.cc#L659
https://github.com/aburch/simutrans/blob/127cc834665e4f07771317d0c511f0a58e9ea235/gui/minimap.cc#L722
Priority is given to bridges and tunnels, and it is not clear from that whether there are any overlapping buildings.

[Freahk]

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

[Ranran]

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.
Would this also be as complicated to implement?

For get_type(), bridges and tunnels are given priority regardless of the ground level. If ignore these, the pixel may not have any data (whether it's the ground or not). If no additional search is done, it will be a black pixel.

Current processing order is to draw the building after displaying the bridge first.
However I tried removing the drawing code of the bridge as a trial, but the data (staffing rate etc.) of the building above the tunnel was not acquired by the current method. (´・ω・｀)

[Freahk]

Currently, we get the ground to paint by using

Code: [Select]

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]

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.

[Ranran]

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

Code: [Select]

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)

Great. Thank you for your advice. It certainly works so it could move on.
Which display/hide option is better, the whole way (but except rivers) or only the bridge and tunnel?
I also plan to move the zoom or isometric view button to the right of "Show map scale" for the new option button.

[Freahk]

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]

/**
 * @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.

[Ranran]

I tried implementing it with minimal changes (without adding additional buttons) as follows:
That is, the "show building" option has the effect of prioritizing the display of buildings over bridges and tunnels.

Displays buildings in gray and stations in red and have priority over bridges and tunnels

I changed the tooltip text in this way but I think this is a terrible translation. (´・ω・｀)

Thanks for any feedback on this.

[Freahk]

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.

[Freahk]

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.

[Ranran]

I'd rather always imply building over way precedence

During the operation test, I noticed that if the waytype was interrupted, the location of the map would be difficult to recognize. It is difficult to understand the position of the place where contour lines, rivers and ways are not displayed. The map of the real world also gives priority to the display of railway lines and may rely on its location.

instead of the "show buildings" checkbox add a "show groud level only" checkbox.

I think "show groud level only" is not good idea. It confuses the option of information player wants to see. I don't understand why the player wants to prioritize the ground level object. I think the player makes a distinction such as "I want to see the waytype information" or "I want to see the building information". The orange and blue color coding supports it. Irrelevant options make that distinction chaotic. So I think the option to switch such priorities is sufficient.

Well, I thought it would be nice to have the option to prioritize the "way" while still showing the building, but I'm wondering if it's worth adding more options to it. And I didn't do that anyway, as adding more buttons would also require tweaking the layout.

Please note that in either case it is not possible to correctly handle the waytype being overlaid on multiple layers. You can stack multiple layers of underground, surface, and overpass. After all, to deal with them perfectly you have to specify the altitude as in the main screen. I don't think it's necessary because the minimap is simple thing.

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.

The current catchment area display distinguishes the goods categories via options, but if they are not selected they are all displayed (and "All" is the default). Therefore it will be confusing if different coloring methods are mixed.

Could you start a pull request please?

Is there a special reason for throwing a pull request? I think it is ready for incorporating, but will rely on James' judgment (regardless of the pull request). I don't always throw pull requests except for small bug fixes. (I mean I don't understand the difference between doing it or not.)

[Freahk]

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.

[Ranran]

When a building related layer is selected, I'd always imply buildings to take precedence over ways.

it doesn't make sense to me to hide buildings

The station is, so to speak, a building above the way. The "show buildings" option has the purpose of turning off the red color of the station. Because, as Vladki initially pointed out, red competes with the color scale.

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.

The tunnel tile is displayed in brown. When "show building" is enabled but the tile is still brown, which means that the tile at ground level does not have a building.

So imho any goods and mail should not use the color coded coverage quality, whilst passengers should.

I would like to leave the color scale of the coverage as is.

1) It is consistent in that it represents the distance (walking time) to the nearest station.

2) Coverage does not represent the actual in-game convenience. In other words, it does not represent the index of convenience of nearby stations.
It should be noted that the nearest station is not always convenient.
For example, there was a small station 500m away, where one convoy headed to the city center station every hour. There was a big station 1km away that could take you anywhere on the map.
Most people will use the station 1 km away.

In the real world, these indicators may appear as "land prices". (However, in the real world, there are factors such as noise and pollution that lower land prices)
Currently extended doesn't simulate such things. Renovation only gradually raises the level of the city center.
If we create a code to show the convenience of tiles, I think it should be done with the new city growth system.


3) Similarly, it does not directly relate to travel time to the destination.
A: There is a station 500m away, but there is only one convoy per day departing from there.
B: There is a station 500m away, but there are countless convoys running all over the map.
Distinguishing between these differences is very complicated.
It will be the station information group(red buttons).

This means that this display simply represents the distance to the station, and it will be very complicated to judge by any further factors (for example, how much travel time can be shortened).

4) As mentioned above, "All" is selected by default. This shows some coverage. This is the player's territory itself.
When passengers and mail have different display styles, handling these duplicates tile is complicated, and the player is confused as to how the display will behave. I also have no idea what it should look like.

Further, comments can be put on pull requests pointing out eventually required changes.

I think the interactions that should take place there are only improvised things like typo modifications.
Basically, I think discussions about patches are led to this forum.

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

I think this has already gotten a lot of feedback and is ready for incorporating.
And after having James check it once, I think it's better to have more people test it at nightly build and get feedback on the development board. Then we can brush up.
So, I throw a pull request once.

[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.

[Freahk]

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.

[Ranran]

I have added the added translatable text to simutranslator.

Perhaps the scale should change labels accordingly. Otherwise I'm for the good/bad scale.

Do you think this can be done just by changing the translation?

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.

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.

For these, I modified the code so that the color scale is reversed, and pushed to my github branch.
However, the problem is that we do color scale at 0-450km / h, so we see almost red or orange red except for high speed track. It is not very useful for this display as it is mostly red in the early periods.
So I wrote an expression that the evaluation changes gradually as the speed increases as based on the square of 450-speed. (´・ω・｀)

Any suggestions on how to do this would be appreciated.

Also not sure about attractions - bigger ones are red. (and bigger circle).

I think this is different from good / bad because it is demand, not congestion. One of the ideas is to fix it to a color that represents a passenger (pink).

Attractions layer - they should include monuments layer (and perhaps town halls and headquarters too).

Regarding Monument, I think that is true. And I think the same is true for the attractions list. Monuments are not included in the attractions list.
The issue is that get_ausflugsziele() does not contain a monument list. However, this is called in many places, so I think it's better for someone familiar with the code to make the changes.
And the same applies to standards. Monuments will not be displayed on the attraction list and minimap in standard.

About town halls and headquarters, I don't think are included here. Or distinguish by color. I think the attraction is a building that attracts many visitors.

Depots - Probably just special colors for each waytype, like for industries?

The color of the depot is originally such a specification.

[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.

[Ranran]

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.

The difficult problem is that these options can be shown at the same time.(´・ω・｀)



My question is, should the color scale of powerlines be reversed?
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?

Regardless of them, I'm thinking of displaying the disconnected power line in the same dark violet as the mail_no_record.

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 think it's a good solution.
Does it need to be waytype specific? Or does it share one maximum speed for all waytypes?

[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).

[Ranran]

degraded red, mothballed black.

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.

[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.

[Freahk]

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

[Ranran]

Degraded has reduced speed limit so it would be nice to see the color appropriate for the reduced speed limit in such case.

Degraded road: wear red (OK), speed & weight same color as if new. For weight it is OK, for speed not.

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 ...)

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.

With speed limit weight limit and wear, mothballed way is colored purple in those option. But I wonder if it's harder to recognize than red. 

Also, the disconnected powerline is colored purple.
And the speed limit and weight limit have reversed the color scale.

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.

I threw a pull request with these changes. I would appreciate it if you could check it after incorporated. 

this is valid only for mail. Passenger stops show coverage even without any service, perhaps walking is counted as service. So this should change...

I think it might require additional coding to do that. 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?)

[Freahk]

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?

[Freahk]

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.