Map styles are a straitjacket that needs to be disaggregated

[Friptick]

Describe the idea (required)

The options blocked by "Map styles" should be unblocked and made available for individual configuration in Profiles.

Tell us about the expected behaviour (required)

This problem has been bothering me for a decade. Time to say something!

In Configure map > Map rendering, there are a bunch of fixed "Map styles" ("OsmAnd", "Topo", "Touring view" etc). Each offers a preset bunch of configurations (i.e., providing different options in Map rendering > Details and Map rendering > Hide).

But these configs are like a restaurant set menu:

• In "LightRS" you can't display "Street lighting"
• In "Offroad" you can't hide "House numbers"
• etc.

Here is my own concrete problem, by way of example. I only ever need one Profile - let's call it "Pedestrian and rail". For this, I want to:

• show clearly outlined footpaths - "Offroad" view has by far the clearest (yes, in town too - in "OsmAnd" view they are all but invisible by comparison)
• show subway lines - this is not even an option in "Offroad" (but "tram" is fine for some reason)
• hide all superfluous clutter - but the only option I have is the mysterious Details > Fewer details, and that leaves a bunch of clutter, for example hotel names

Isn't this kind of granular control the reason for having Profiles ("Walking", "Cycling" etc)?

It seems you can control almost everything with Profiles except the most important thing - what the map actually looks like, which is blocked by whatever's available in each "Map style".

Tell us about alternatives you've considered (required)

Use Organic Maps, which has better control of POIs.

Context (optional)

No response

[sonora]

It is true that a "Map style" governs the following:

(1) The appearance of how things look in terms of area colors used, road colors used, road styles used, accentuation/thickness, etc.

(2) What objects are shown at all, mainly derived from the assumed (but certainly not necessarily correctly assumed) purpose why a user would select that Map style.

(3) What configuration options to show to users to facilitate customizing this (mainly regarding (2)).

(4) In addition, most map styles are only "dependent" map styles, i.e. for anything in (1), (2) or (3) fall back to a parent Map style (usually the OsmAnd default style) to govern where they do not specify anything deviatiing.

So, in a sense, our Map styles are pre-packaged configurations to use the map in certain appearances suggested for certain purposes or use cases.

In essence, are you saying that (1) is a good concept, but regarding (2) the set of Show/hide/Details etc. configuration options should be de-coupled from the Map styles and should always be the same?

It sounds viable, but you would lose tha ability to create Map style specific onfiguration options. And this would probaly also result in 'nonsense' options which have no effect for a certain Map style, or creates display conflicts by facilitating to enable features which ovetlap or are not distinguishable from each other by their appearence in the selected Map style.

Perhaps the way to go is to follow your suggestion to some extend, by looking one by one which option you are looking for is not available in what Map style, and if there is a necessity or justification for this.

[Friptick]

Thanks for the thoughtful reply.

In essence, are you saying that (1) is a good concept, but regarding (2) the set of Show/hide/Details etc. configuration options should be de-coupled from the Map styles and should always be the same?

Exactly. That is the most obvious solution, but I am absolutely open to alternatives.

As you imply, there is clearly a distinction to be made between two things:

• appearance - color scheme, line thicknesses, point sizes, text size
• content - what is shown and what is not

I get that a user who chose "Winter and ski" will want to configure "Difficulty of horse trails" more than one who chose "Nautical". You're trying to limit the useless choices and possibilities for nonsense results.

The problem, I believe, is that the current functionality is arbitrarily limiting while still being complex (it took me a while to even understand that the Map Style was blocking off other options "upstream" in the UI).

To return to my predicament (which I have been working around for literally years): I want a specific combination of appearance and content that works for both walking and taking trains (i.e. heavy trains, metros and trams - not buses or other road transit). Basically:

• thick, super visible footpaths
• all rail and metro and tram lines, plus their stations
• no random POI detritus like hotels, churches, bus stops, traffic lights - nothing

This would be absolutely possible if I had full control over lines and POIs, but it's not possible currently. And it's not just an esthetic annoyance, it really limits the usefulness of the app. For example, when I am visiting a new town I have to hope that the local metro is an above-ground metro, otherwise "Offroad" view (which makes footpaths very visible even in cities but does not show subways) will be useless and I'll have to switch to "OsmAnd" or "OSM Carto" style and accept semi-invisible footpaths. And even if the the metro is not underground, "Offroad" view still has the clutter (hotels, bus stops, etc) which I can't get rid of even when selecting "Fewer details" and unselecting everything else. It's frustrating to know that if I could just control this with a bit more granularity, I could fix all this and never have to fiddle with it again.

The quick solution to this would be to add yet another Map Style for urban hikers who also take trains (I'd accept that gratefully!). But I think the right solution is, as you suggest, to do some decoupling. Possibilities:

1. decouple appearance from content, and make the content (i.e., which POIs and line types to show) configurable with full granularity for each Map Style
2. same, but also make the appearance configurable (after all, perhaps a "Desert" user actually wants roads like a "German road atlas") - in my case, for example, unless this is configurable, I will have to keep using "Offroad" everywhere because it's the only style which makes footpaths properly visible on my screen
3. add a "Custom" Map Style where absolutely everything is configurable, and base it on "OsmAnd"

Option 3 is the pattern often used with graphic-equalizer profiles. For when "Jazz" is too tinny but "Classical" has too much bass, there's the DIY "Custom" option. That could be a great solution.

What do you think?

And it goes without saying but thanks for your work on this project. It's really appreciated.

[sonora]

Let's see what other team members or product management think.

One more comment for completeness; Please note that also the App profile selected can have impact. In e.g. my Touring view style, footpaths will be significantly more accentuated in the walking profile (or other foot-based custom profiles) than in the other profiles.

But it sounds like the Touring view will not well solve your particular issue, as it also aims to show all things which can serve well as landmarks and orientation marks, which per your use case description you probably rate as too much clutter. 😉

[Friptick]

Thanks.

In e.g. my Touring view style, footpaths will be significantly more accentuated in the walking profile (or other foot-based custom profiles

Indeed, some of the footpaths are black! Amazing. Others are still hard-to-see red. But how? I had of course experimented with the Walking profile but it seemed it was only changing the UI, rather than the map, which was done by "Map rendering". I have been using this app for years, and it took you to point out this trick. Where are these micro-adjustments even being arbitrated? This discovery makes it even clearer to me that the map rendering config needs to be more transparent, and where possible not result from unpredictable combination effects. Or at least that we need a Custom map style which has the power to override everything.

which per your use case description you probably rate as too much clutter

Yes I probably do. And should that not be my call?

Judge for yourself. This is an Offroad view of a part of Istanbul.

The major problem is that there's an underground metro line running right thru this, but Offroad map style doesn't show subway lines. (Touring style does show them - but its roads are hugely thick, because it's meant for cars.)

It's not bad otherwise: the pedestrian-only streets are obvious, there are a couple of clear dotted footpaths and a very clear stairway at the bottom.

But still, I'm on a street corner, in the sun, squinting at a little screen trying to make sense of a map. And there are a bunch of things I just do not need to see on it: hotels (plus their names in text), bus stops, churches (plus names), traffic lights, one-way arrows for cars, what looks like an administrative boundary, etc. So yes, I do consider this "clutter". And the whole point of OSM is that you can configure it yourself, right? Well. that's all I'm asking of OsmAnd.

Thanks for considering.

[sonora]

Re "clutter": Have you played with the Configure map>Hide menu? In Touring view e.g. POI labels can easily be hidden there if you want to hide things like hotel or church names.

Also: Touring view does not target cars, but all means if transportation, adjusting for these via the App profile selected.

[Friptick]

Indeed. With Walking profile, Touring view is slightly better than Offroad view for that reason, and also because it shows underground metros - hallelujah. So thanks for the tip.

But otherwise the improvement is marginal. The main roads are unnecessarily huge; the contrast of smaller roads is too low; and most of the footpaths are still in not-very-visible red (I guess because, the last time I checked, OSM had about 10 semi-arbitrary varieties of footpath). So: swapping compromises for compromises.

I suspect you think I'm being overly pedantic about what seem like small differences. Fair enough. In my defense I use this app a lot so I know exactly how the map would be most useful to me, and I know that there are no technical obstacles to that except OsmAnd's UI decisions. So naturally I'm a bit frustrated by the situation. I only speak for myself but maybe there are others suffering in silence too!

Thanks in any case for listening, and for the little tip.

[DmitryAlexei]

This issue intersects with this one https://github.com/osmandapp/OsmAnd/issues/18055 It is not clear, that the displaying of POI and roads depends on the selected profile.

[itzikiap]

@Friptick You're not being pedantic, you're right. Map style should affect only the style (colors and geometry), as the name implies, all other parameter should be independent. I guess that technically all goes to render.xml, but this is none of the user's concern.

[sonora]

Yes, technically you can just create your own render.xml file (either depending on an existiing Map style, or from scratch) and produce exactly the map view you would like to have.

Problem is that this is rather tedious coding work, even for a developer-grade user, and we have never developed a UI to make this more user accessible.

And map style development does not stop there: Ideally it involves a lot of testing and verification, even nuances in color make a visible difference, ideally verified in lots of use cases and light conditions, see e.g. https://github.com/osmandapp/OsmAnd/issues/15779#issuecomment-1366718327.

If you find it helpful, I could investigate accentuating the road casings of small (white) roads in Touring view's Walking mode further (assimilating how Offroad does it). The reason they are not too pronounced is to not produce too much visible clutter in city and residential areas, which is more of an issue for driving through these areas, less so in a walking profile.

[Friptick]

Interesting insights.

So, a Custom map style with 400 checkboxes and sliders and full power to make the map very ugly - is it hard to implement or just not your preferred solution on UX grounds? What if it were hidden behind an "Advanced" warning?

If that's off the table, then I think the priority should be to make it clearer that Profiles can subtly affect Map Styles. I went for years without understanding this. I assumed that "Walking" et al were just clones of "Browse map" except with a bunch of different options preselected.

If you find it helpful, I could investigate accentuating the road casings of small (white) roads in Touring view's Walking mode further (assimilating how Offroad does it).

Absolutely, this would be helpful and appreciated, yes. With footpaths blackened or thickened, that is coming close to ideal for me personally. To be honest I think that all the map styles would benefit from more visible footpaths - it's pretty hard to see a 1 pixel dotted line on a small screen in bright outdoor light.

[sonora]

I have increased the accentuation of pedestrian-related ways for the Touring view Map style some when used in a pedestrian-based App mode. Is available in nightly builds and next release.

[Friptick]

Much appreciated.

I stick by the original issue here. I think the baseline solution is to open up the styling completely for advanced users who think it's worth their time and are happy to break things. Via a "Custom" map style or similar. For comparison: Firefox has a bunch of colors options, right in Settings, where you can easily make every website green with invisible text if that's what you want. OsmAnd should also let its users off the leash, IMO that's the point of FOSS. This app is already known for being powerful and complex, seems a pity to be blocking users with semi-arbitrary design choices in the all-important domain of map rendering.

Separately but relatedly, if Profiles are to continue having a subtle influence on Map Styles, then this needs to be made clearer.

Not complaining, just giving feedback as a user of many years. Thanks for your work.

[sonora]

IMHO, one of the purposes of having App profiles linking to your mode of transportation is of course that they also configure/optimize the map appearance accordingly...

[Friptick]

Sure, I'm not contradicting that. I'm saying that:

• if a feature has subtle effects on map rendering that are not configurable, then this fact at least needs to be made more clear - the current functionality is unintuitive
• the proper solution is some kind of configurability - power users will always have their preferences and priorities, and should not be reduced to begging you for micro-adjustments (despite your helpful tweaking, I know exactly how I would still like to change the map, but I cannot)

@vshcherb has now added the dreaded "Nice to have" label, so it seems none if this will be done. That is disappointing.

[vshcherb]

Actually for this year we plan to change control over icons, so user will be able to configure at least icon groups visibility and their view. Configuring lines appearance is actually very tricky unless you edit map style itself

[njam]

Maybe it's worth considering to only ship a single map-style, and implement the features needed by the different app-profiles in this default map-style. For example the "Hiking" app-profile will enable rendering of footh paths and public transport routes, and hide unnecessary clutter, all in the default map-style.

The other map-styles (like "Offroad", "Topo" etc) would be hidden for the user by default, but can be enabled if desired.

This could help to bundle developer efforts. An improvement made for "Hiking" (an app-profile) might also be useful for "Skiing" (a map-style).

[Friptick]

Agree with @njam. In fact that is roughly what I am proposing in this issue.

It is confusing UX to find an option for an "Offroad" map style when the "Public transport" profile is enabled.

It is even more confusing to discover (as I did after many years, see above) that changing the map style does not just change the list of available rendering options - it also changes the rendering itself (line thicknesses, etc) with no control left to the user.

As @njam suggests, a better solution would be to

1. get rid of fixed map styles
2. have a single universal set of checkboxes and sliders for map rendering
3. set their default values according to map profiles