"Killer feature" (OsmAnd unique selling point): Provide better low density maps <= 11 zoom

[sonora]

I have had this feature in mind for a long time, and think it is now about time we try this, and with it create one more killer feature which promotes OsmAnd over almost any other available mapping app:

As we all know, in general the amount of detail to be shown on the map at close-up zoom levels (say >= 12) needs to be limited to avoid the map screen being cluttered with details. We are doing a fair job here with our "minzoom" mechanism, limiting and controlling the amount of detail visible via a variety of high or low detail renderers and switches (like e.g. he "more details" switch) for what users may require.

But we have neglected the complementary situation: Some very large areas in the world are rather feature-deprived so we could on the contrary enhance the amount of detail visible there. In order to discover anything at all, you need to zoom out rather far (to view a large enough area to find anything), and the crux is that at these small zoom levels we do not render many details any more. But displaying these features may be very essential for the usability of a mapping app in these areas at all.

Examples of this could be as follows:

• Take an Alpine area. The things you may definitely NEED to see are hiking trails and Alpine huts, even at zoom <=11.
• Take areas like deserts. While there may be no roads, there may be tracks and paths. And there may be springs. You may need to zoom out far enough to find them (maybe to zoom 11 or 10), and it is counter-productive if at such zooms we do NOT render them, instead show and "empty area"
• Take thinly populated scenic areas like the north of Norway. There may be very few things, and tourists may try to discover things like the polar circle visitor center, a feature we only render if you zoom in rather far, while google maps shows thee things (in the absence of other features) much sooner.

So my suggestion is we find a dynamic mechanism, perhaps along the lines of our existing roadDensityLimityPerTile, to include OSM features in map tiles which would otherwise contain very little detail, at smaller zooms than with our static "minzoom" mechanism.

Please note that we would only do this in situations where there is zero issue with cluttering the map, I am talking about areas where we would mostly show an "empty map", while there is very useful information "hidden" for the user. I am not sure if we would e.g. directly include this information in our base map at lower zoom levels where needed, or if we could e.g. "extract" this information from the detailed maps' higher zoom levels and somehow project and display onto the lower zoom levels.

Another note: We do have a workaround for POIs to display them via the POI layer mechanism, so the initial focus for this request could lie with tracks and paths, not necessarily POIs.

[vshcherb]

I think if we manage to solve it for zoom <= 11, we will find a solution for zooms higher. Actually I'm thinking the right way to start doing it, to investigate roads which are not part of any admin_level >= 4 (let's say). Before we start building something, we need to have verbal algorithm how to do it. Today implementation with road density is quite bad, because it doesn't sound natural and it is not easy to make decision whether to show it or not. Let's think something better and please let's share urls/examples of such areas on the map.

[sonora]

Yes, good plan. Let me start by showing the purpose of what we are doing here with 2 examples.

Screenshot series "Nevada" shows a largely uninhabited desert area. On our maps (and in most other map implementations, so we can create a killer criterion for OsmAnd here!) the nearest "signs of civilization", the 3 surrounding highways bordering the area, are visible on the overview zoom 09 (note the 20km scale!), but with no road details in the middle at all. Now you have to zoom in all the way to zoom 12 (the 2km scale indicator!) to start seeing your travel options (there are numerous tracks passable by cars, offering both regular travel options and emergency options. But of course at zoom 12 you need a LOT of panning ...) What I am saying is we should how these tracks already on zoom 9.

My second example shows a more inhabited and well traveled area in southern Arizona. The area has many graded dirt roads or even paved roads, the main ways of traveling other than on the few major highways. Again, you have to zoom in to 12 to see this web of interconnecting the highways. For travelers in this area, it would be advantageous t see this earlier.

[vshcherb]

I checked that area, unfortunately even in that empty area there are issues http://www.openstreetmap.org/#map=15/38.6342/-115.5161 (so many tracks will create a noise and will be visible as a spot) rather than a line. Another your example http://www.openstreetmap.org/#map=12/31.5395/-109.5533 surprisingly Mapnik also doesn't display the roads on 11th zoom. Do you have any example of a good map, possibly even paper one one of these places.

[sonora]

I know, even Mapnik is completely useless here, that's why I say we have a chance of beating them all here ... :)

To you points:

• Yes, certainly we have to consider noise, because not all areas where we show "nothing" are really "empty", my point exactly. That's why I suggest something like an automated density approach: Wherever we show really few roads, we can dig for more and render them, too. I think this can be automated, we may even already have the basic mechanism in place with our renderingAttribute "roadsDensityLimitPerTile" ?
• In general, noise in empty areas is not much of an issue, you can do this experiment: In OsmAnd go to the above Nevada area, zoom 12 so all the tracks are displayed. Now use the smallest map magnification we have available (long-tap on any zoom button, chose 33%). The result on the screen is quite acceptable and gives an impression how things could look at zoom 11 or 10.

I will send you screenshots and map photos by PM so not to spam this issue further with large files..

[vshcherb]

If we focus on AZ usecase, can you please calculate phisical scale. The map you sent to us has 1 : 250 000. If you measure the ruler of "good zoom" - 12(?) and expected zoom - 9 (?), can you say what is the phisical scale. Please if it is not difficult try map magnifier 33% and 50% and give the scale

[sonora]

Victor, not sure what you are asking here, but let me try:

There are scale bars at the bottom of the topo map I provided. From Downtown Douglas (bottom of the map) to the Arizona/New Mexico state border (right hand edge) we are talking about 127km, let me take this s the reference distance.

• A paper topo map would typically take 56cm to cover this distance (within a factor of 2, depending o what map type and quality you have) On a typical 4 inch screen, like outdoor people would carry it, we are talking roughly (and I verified with our Osmand scale bar)
• 100% zoom 12: 54cm (exactly like the paper topo map, so of course most of this distance is now off-screen)
• 50% zoom 12: 26cm
• 33% zoom 12: 18cm

(I think this is consistent, the discrepancies are extrapolation errors. Can be verified with our OsmAnd scale bar, but please note that it updates only after a brief zoom operation, not immediately after changing the map magnification value.)

Now for zoom 9, to fit it better on the screen

• 100% zoom 9: 6cm
• 50% zoom 9: 3.4 cm
• 33% zoom 9: 2,4cm.

Is that what you mean?

So you see, when I first designed our what-to-how-t-what-zoom concept., I made zoom 12 the "zoom to show all roads and paths", essential, which brings us in line with Paper topo maps at 100%. But now we could be better, because we have electronic maps! We could "fill" the mostly empty screen on zooms 11, 10 or even 9 (where only the primary highway is displayed) with some more data.

Best, Hardy

On Sun, Aug 9, 2015 at 12:40 AM, vshcherb notifications@github.com wrote:

If we focus on AZ usecase, can you please calculate phisical scale. The map you sent to us has 1 : 250 000. If you measure the ruler of "good zoom"

• 12(?) and expected zoom - 9 (?), can you say what is the phisical scale. Please if it is not difficult try map magnifier 33% and 50% and give the scale

— Reply to this email directly or view it on GitHub https://github.com/osmandapp/Osmand/issues/1444#issuecomment-129059284.

[vshcherb]

That means paper map: 1 cm - 226 km 12 zoom: 1 cm - 226 km 12 zoom 50%: 1 cm - 552 km 12 zoom 33%: 1 cm - 705 km 12 zoom 25%: 1 cm - 1104 km 11 zoom: 1 cm - 552 km 10 zoom: 1 cm - 1104 km 9 zoom: 1 cm - 2208 km

[vshcherb]

So what I see we have very good picture of 12 zoom 25% and goes down up to 10 zoom! Of course we have a technical issue how to get it working fast but the picture is something what you would like to get.

[vshcherb]

Technically saying the roads are almost the slowest bit, display map data from zoom 12 on zoom 9 (that's what magnifier does) we could gain only on simplification of the lines (on 9th zoom we could simplify more), on the other hand if we can't distinguish between 2 type of lines, I see no possibility why 1 should be displayed and another not. Can we reiterate map knowledge to say that one track path is more important than other based on tags and not based on distance from major roads.

[sonora]

I have been thinking abut this a lot now, and see no use in trying to prioritize things (tracks, etc.) where we do not know much about the local situation.

So the only strategy I can come up with is what I have been saying all along: Let us count the total number of items of a certain type (like highwaytrack /path line segments) visible on the selected screen, and treat it as a "density indicator". If the number is extremely high, you are likely viewing a city area, so we have no issue and no reason to improve on our current "static minzoom" strategy (the map will be crowded anyway). If the number is "medium", you are likely viewing a well-mapped area in a densely populated region, with a significant number of roads visible already, likely also no reason to improve the map display. But it gets interesting where the density displayed is low or extremely low, like where only very few highway segments (maybe tertiary and up) are visible. There it is VERY likely that a considerable improvement of the map's usability could be achieved by adding more lines, like tracks or even paths (which would otherwise only displayed at higher zooms). Doing this would normally not overcrowd the map in such areas.

We could assume the same strategy for the display of POIs, by the way, which would make springs in deserts or Alpine huts in remote mountain areas visible at much lower (overview) zooms than we have today with our static minzoom strategy? This would greatly improve their "discoverability" on the map.

Best, Hardy

On Fri, Aug 21, 2015 at 6:29 PM, vshcherb notifications@github.com wrote:

Technically saying the roads are almost the slowest bit, display map data from zoom 12 on zoom 9 (that's what magnifier does) we could gain only on simplification of the lines (on 9th zoom we could simplify more), on the other hand if we can't distinguish between 2 type of lines, I see no possibility why 1 should be displayed and another not. Can we reiterate map knowledge to say that one track path is more important than other based on tags and not based on distance from major roads.

— Reply to this email directly or view it on GitHub https://github.com/osmandapp/Osmand/issues/1444#issuecomment-133482176.

[gorn]

I agree that this would be a killer feature. It would be really usefull in hiking mostly deserted areas. I think that in many cases you do not switch very fast between "dense" and "void" areas, so it could be absolutely enough to introduce "vanilla" versions of the feature.

Vanillla version would look like this. User could adjust a constant x, which could be 0,+1,+2,+3 etc and it would be added to zoom for purpose of level details which should be displayed. I.e. if I set it to +3 and I am on zoom 12, OSMAND would display details as if was at level 12+3=15.

It looks very basic, but I believe it would solve lots of cases even in this simple version. (And it would be interesting to collect usage data from users who would agree on it - to see at what coordinates what adjustment is used. This knowledge would be than useful in implementing more refined version of the feature)

[DFyson]

This is a brilliant idea! I can think of several recent uses when this would have been really handy to have, mostly when in lower populated areas. It would really revolutionize the way map data is displayed, away from the old 'static' map idea (although having consistent maps at a specific zoom could still be useful in some cases). For example I was recently looking at Northern Canada and it looks empty up there even though there are communities. However they are small and far apart and don't render until very zoomed in so it's difficult to visualize them. I used minimum map magnification which helped but it could be much better.

I wonder if the best way to do it is by having different files for map rendering priorities. So the renderer would render objects following a list of priorities until the map reaches a certain complexity (map density). So for example someone who is in biking mode would want bike self-repair stations, bike paths and maybe drinking water as high priority, and car parking would be low priority and only rendered when there is little else to render. But someone in driving mode would want parking a top priority and hiking trails and bike repair stations rendered last. Then in the options, one could change the map density depending how cluttered they want the map instead of the details → more details, and to have more consistent performance on older devices. For example 100's of buildings in a city isn't very useful to me and gives a significant performance hit on older devices, but back country skiing it is useful to see the occasional cabin in the woods.

[tazva]

Did this ever go anywhere? It would be great to have while travelling.

[ADepic]

Any updates? @Future_Milestone ??

[akkana]

This would make a huge difference in the US west. We have the same situation in New Mexico as shown in the Arizona screenshots, where frequently there are only a couple of roads shown on the screen and none of them have a label, and you have to zoom in 3-4 times just to get the names of those major roads, let alone see the roads you need.

I've addressed this with custom styles (mostly adapted from styles posted on the mailing list) that show roads, tracks and trails at much lower zoom levels. But it would be fantastic if the normal OsmAnd styles could adjust the level of detail when needed, without requiring any custom style hacking from the user (not something I could easily explain to my less geeky friends).

[sonora]

Yes, honestly, I am not sure why we havn't made it to follow up on this in all of 5 years or so ... I guess it is because the majority of the OsmAnd team is concerned with Europe, where the situation is crowded so the issue is mostly to have too much detail on a map, not the other way round ... ;)

Similarly, I had years ago also posted my suggestion this to our friends at openstreetmap.org, but I do not think they took any steps to amend their standard Mapnik or similar on their web site in this fashion either.

The issue with just hacking an OsmAnd renderer is that it will not pick up detail which is not present in our map source files at that zoom level. We would either need to implement a mechanism where things are cross-picked up from a higher zoom level, or already add this data to lower zoom levels at map file creation time. When I authored the "Touring view" map style, I think this is close to the most you can achieve with our current mechanism and data (if you also select the "More details" flag under the"Details" menu).

[vshcherb]

@sonora I think issue could be crosslinked with detailed Basemap, since now we don't have limitations with small basemap, we can actually try to provide very detailed basemap up to zoom 10 including with all possible roads up to 1 GB. I think in that case rendering style could pick up these details

[sonora]

@vshcherb Hi Victor, yes, that was my thinking exactly... and the reason I started responding to this to this real old idea. :)

Whether we actually pick up data from higher zoom levels or an improved basemap does not really matter from a user perspective. The one thing we could try to do, though, is some automated "map crowd control", meaning we flag and add certain (essential) data on map screens where there is otherwise little data shown, while in high-density map situations (cities) we would automatically suppress: I.e. a built-in feature or switch, need for a special "remote area" renderer or anything.

[atorstling]

This feature is one of the areas where paper maps still have an edge to digital ones. It would be a huge improvemt if you could fix it, even if it was by means of manual tagging.

[vshcherb]

I'm closing this issue cause current basemap is much more detailed, especially after adding features for "desert" style. The fix was to lower basemap zoom from 11 to 8, there is almost no practical point to find details on map from 1-8 zoom and make it only nicer. Don't forget that Zoom Magnifier can really reach +2 zoom levels.

[sonora]

Well, what this issue actually suggested is a dynamic behavior: Instead of simply and flatly including more detail, which will clutter the map in already dense city areas and degrade rendering performance, or adjusting the map zoom, which requires manual user intervention and most are not aware it exists, I am suggesting an intelligent and automatic behavior where the app would detect a significantly low density map screen and as a result adds detail by itself, drawing from the next higher zoom level(s). This is how we would beat manually redacted paper maps by an algorithm. It clearly goes beyond just flatly 'including more detail'!

[vshcherb]

Agree that dynamic would be a great solution though it doesn't look like we have a good approach for that

[ADepic]

Can you as "out of reach" or "out of scope" label to this issue to show it would be ideal but is currently not feasible?

[vshcherb]

This is pretty old issue, I would like to keep it close in order to let people generate "fresh ideas" based on current situation with current screenshots etc. The situation has changed for last 4 years, especially for desert style. It wasn't completely about "dynamic" approach it was also about "manual" approach. Feel free to create new one with new observations

[gorn]

I am sorry, but I do not see how the situation has changed. The desert case is still unsolved and it was only an example of a deeper problem. I do not think filing new issue with the same ideas will take as any closer tho the solution. If this is "good idea, but we do not have mapower" than it should be archived as such.

[sonora]

My idea involves essentially 2 steps:

(1) At the selected map zoom z, count the number of objects depicted on the current map screen (to detect a "low density" map section). I think this cannot be too difficult, we do even have <renderingAttribute name="roadsDensityLimitPerTile">, measuring/governing something rather similar already (in this case just for roads).

(2) If this number of objects is below a threshold, look up the objects from the next higher map zoom z+1 which have minzoom=z+1 (i.e. which are just not displayed at the current zoom level z), and paint them into the current map screen (zoom z).

(3) (Recurse with z+2, if needed, but this is probably not necessary)

I agree that (2) is not trivial, but not impossible either?

[vshcherb]

@sonora that's interesting of course though it requires time to implement just to experiment :-)

2. The problem of map panning, you don't want to ruin your map experience if you move the map a bit and you get completely different map view for the same area.

Of course it is possible to introduce consistency by splitting to the tiles but that wouldn't be consistent for 2 near by tiles. All paper maps use administrative or natural boundaries to display certain object types i.e. in the park major pedestrian roads might be more visible than pedestrian roads next to the park.

I would say one of the first feature to implement is rendering based on certain administrative borders

[gorn]

I think that @sonora idea is correct. I think it would even be possible to precalculate large regions where this "zoomdrift" could be applied. The aim is NOT to change it every few hundred meters, but to have refions with almost no information covered well (deserts, high mountains).