Better support for areas with little content, e.g. allow downloading in lower zoom levels

[georg-d]

Use case
Some areas like cities have a high density of content while other areas have little content, e.g. deserts, mountain ranges, rural areas, stretches of sea. In such "nearly empty" regions, SC is neither easy nor comfortable to use:

1. The map rendering is configured to ignore most features that serve as landmarks in rural areas, so the map appears mostly empty and in direct sunlight (high in the mountains, there is no tree offering shade!) the very few existing white lines on yellow-orange background offer so little contrast they are hard to recognize. This makes orientation really difficult. So difficult, I cannot localize above screenshot on another map in 2min timebox on locatio (i.e. in direct high altitude sunlight), even on an OSM based map (i.e. exactly same shapes/geometries), and even though I know it's around Gaschurn (i.e. I know where to look), and even though I know the terrain as I was there one day, e.g. on https://www.openstreetmap.org/#map=14/46.9558/10.0182&layers=C
2. As in these areas, we are quite often offline, we cannot download continously as we go but we need to download quests in advance. But this is unneccessary difficult because search for quests requires to zoom in a lot, despite there are so few objects that even on low zoom level, download size will be very small. And because of 1, it is quite difficult to tell where a tour will bring me to, and also to manually stitch together / tell apart the single small map area one can download quests for.

Proposed Solution

1. Also render objects that are usually good landmarks in such regions. In the mountains, elevation lines (every 100m shall be sufficient for rough orientation), peaks, aerialway and glaciers are like streets, railroads etc are in cities.
2. If possible, render objects paths, buildings, etc. already on higher zoom levels in case nothing / little else is rendered for "a tile".
3. Also on low zoom level, allow to download quests. In order to avoid "too high" data transfer amounts in areas with many objects, we may e.g. limit download to 500 results, or first check rough amount of objects in current bounding box to decide whether more zooming in is required or not, or display the maximum sized bounding box as rectangle above the map and ask whether data for that area shall be downloaded (so the bbox size is as big/small as it currently is, but in rural areas, some "remote" landmarks like villages or streets are visible for orientation).
4. Instead of only allowing downloading a rectangular bounding box of visible map, allow download along route and/or inside polygon and/or with user definable size. For example, allow to import a GPX file with a track or route and to download either along that route (e.g. within 150m distance) or within the polygon defined/enclosed by a closed round-trip track/route. Like this, users could plan a tour or download region in another app having usable rendering in the target area, export as GPX, import in SC and download map & quests. Alternatively, the "set center and radius for download" approach mentioned in Use cases for Quest Presets #2457 (comment) so the region shown in the map may be quite big (=low zoom level) for orientation while download region is much smaller than visible map.

[smichel17]

I think downloading at a lower zoom should be do-able. We already have logic for checking the density of quests in a small area and then calculating how large an area to download based off of that (used for auto-download). So we would "just" need to apply the same strategy to manual downloads: First check some smaller bbox in the center of the download area. If the estimated number of quests in the requested area is small enough, proceed with the download; otherwise, request that the user zoom in further and/or download the largest area which a small enough estimated download size.

[westnordost]

It's not that easy. The "automatic density detection" works by first downloading a very tiny area around your location and only measuring the density in that tiny area. Imagine you are on a country path a few hundred meters away from the next village. The density is almost 0 in your immediate vicinity. But in the next village, it is drastically different. If one builds on this detection too much, StreetComplete would download a massive area if you are just out of that village/town.

And the same applies to cities. Density can be very very different depending on where you are. E.g. if you are in a residential area, the detected density may be so-so. But let's say the download bounding box intersects with a primary road on which there are half a dozen bus route relations. Then suddenly, just because of that, the download will be huge.

Finally, as @smichel17 noted, the manual download does not have this detection at all, it just downloads whatever is in view (if you are not too far away). Adding this to the manual download, even if the detection would be really reliable, would mean that the user will not immediately get the message "zoom in further" but after some downloading has been done. I think this would be bad UI.

The other suggestions (download along a GPX route) I find are quite advanced, TBH I don't see this in an app that is supposed to be easy.

Also render objects that are usually good landmarks in such regions. In the mountains, elevation lines (every 100m shall be sufficient for rough orientation), peaks, aerialway and glaciers are like streets, railroads etc are in cities.

Good idea. At least peaks should be available in Jawg. The rest doesn't seem to be available. See streetcomplete/streetcomplete-mapstyle#104

[matkoniecz]

Are you sure that aerialway data is not in Jawg? This seems quite typical thing to render.

[westnordost]

aeroway is there, not aerialway.

See https://www.jawg.io/docs/apidocs/maps/streets-v2/#layer-reference

[westnordost]

So anyway, apart from the peaks this is a will-not-fix.

[georg-d]

I just came back to this during preparation for a stay in the Alps. I still would strongly prefer to use SC in these areas because it does pro-actively ask about "missing" keys/values, while e.g. Vespucci requires to manually open each object's tags and click the plus icon to see empty values – a discouraging low hit rate...

The "automatic density detection" ... If one builds on this detection too much, StreetComplete would download a massive area if you are just out of that village/town.

Two completely different approaches came to my mind:

1. Is it easy to limit the download size in bytes, e.g. by telling the server's API to not add any more objects when e.g. 500kbyte are in the buffer? If yes, we could allow users to trigger manual download at any zoom level without coincidently overloading the server. That would increase server protection in a crowded area, because currently allowed zoom level based approach could already mean a lot of data. At the same time, that would allow a huge bounding box in a nearly empty area.
2. Does SC have access to map tile metadata, i.e. how many objects are rendered in a tile? That is a reliable, rough indicator of highest possible amount of quests: Where nothing is, no quest can exist. Where 10 objects are, quests for max 10 objects can exist.

The other suggestions (download along a GPX route) I find are quite advanced, TBH I don't see this in an app that is supposed to be easy.

👍

Also render objects that are usually good landmarks in such regions. In the mountains, elevation lines (every 100m shall be sufficient for rough orientation), peaks, aerialway and glaciers are like streets, railroads etc are in cities.

Good idea. At least peaks should be available in Jawg. The rest doesn't seem to be available. See streetcomplete/streetcomplete-mapstyle#104

Is it easily possible to render natural=scree and/or natural=bare_rock and/or the name of lakes (can't cover other objects as there are few OSM objects on lakes)? All of that would help orientation in areas like https://www.openstreetmap.org/#map=16/46.9017/10.0120&layers=Y

[westnordost]

Is it easy to limit the download size in bytes, e.g. by telling the server's API to not add any more objects when e.g. 500kbyte are in the buffer?

No

Does SC have access to map tile metadata, i.e. how many objects are rendered in a tile?

The tiles on OpenStreetMap is a rendered PNG, the object density cannot be ascertained from that. The tiles from jawg.io do contain vector information, so they differ in size depending on the data density. But, only a very small subset of the data is represented in those tiles, as you see on the map - just roads, buildings, paths. Nevertheless, it could theoretically be used to gather a very rough estimate of the data density.

[smichel17]

Sounds like a next step would be for someone to do some testing: download a jawg tile in various coordinates, then trigger a download of the same area of OSM info, and then report back with the results