search

OpenHistoricalMap / issues

File your issues here, regardless of repo until we get all our repos squared away; we don't want to miss anything.
Creative Commons Zero v1.0 Universal
18 stars 1 forks source link

Show heatmap of data density on main map #817

Open 1ec5 opened 3 months ago

1ec5 commented 3 months ago

To a new user unfamiliar with the things this community has focused on mapping, the initial map looks barren, blank. OSM had this problem originally, but we will always have this problem to some extent because not all of history is known to a great degree. Users need a more effective way to discover areas that have a lot of great mapping that they can count on. Although OSM is no longer so sparse, some themes continue to be very sparse, such as indoor mapping. To improve discoverability, the major OSM-based indoor maps, OpenLevelUp and indoor= both default to overlaying a heatmap that visualizes the areas of relatively high density at relatively low zoom levels. We could add a similar heatmap to our main map at low zoom levels to help surface our hidden gems.

In MapLibre GL JS, it’s trivial to add a heatmap layer based on vector tiles, but the vector tiles have to already contain all the data being aggregated. This is impractical at low zoom levels and would defeat the purpose of the feature. Instead, we need to somehow precompute the density data and encode that in tiles. Ideally we’d also enable the heatmap to vary over time, but this could complicate the server-side computation further.

1ec5 commented 3 months ago

This QLever query gives an idea of what the heatmap would look like across all time. The distribution would look somewhat different on any given date.

Heatmap with hotspots in the United States, western and central Europe, and Japan

1ec5 commented 3 months ago

To improve discoverability, the major OSM-based indoor maps, OpenLevelUp and indoor= both default to overlaying a heatmap that visualizes the areas of relatively high density at relatively low zoom levels.

OpenLevelUp’s heatmap is based on clustering the individual results of an Overpass API query, which obviously wouldn’t scale for this purpose.

indoor=’s heatmap is a vector tile layer, which is exactly what we’d be implementing. Their tile generator is powered by OpenMapTiles, but the SQL queries are relatively straightforward and would probably map seamlessly onto our Tegola-based tiler.

This QLever query gives an idea of what the heatmap would look like across all time.

QLever’s heatmap implementation is strongly tied to SPARQL results, so I don’t know that we’d be able to reuse it as is.

indoor=’s approach would be the way to go.