Specify behavior/appearance for low zoom levels

[ppawel]

Right now in OWL you can generate tiles for any zoom level. However, it does not really make sense to generate tiles for low zoom levels (1-8 or even further, 1-10 or 1-12, this is TBD as part of this task) since the geometry would probably cover the whole tile and be unusable, not to mention it would kill any web browser.

So, we need to think what to do about that. Some options:

1. Original OWL did nothing - you had to zoom in to at least level 12 to see geometry.
2. We could aggregate high zoom level tiles into low level zoom tiles to generate some kind of indication of "hot spots" or "activity spots" or whatever - areas with lots of (recent) mapping activity.
3. ...? Any futher ideas?

Options (2) and potentially (3) would require some additional API but I think here in the owlviewer project we should talk mostly about behavior/appearance and API details can come later.

[lxbarth]

I have been thinking about this, and I think we should aim for this iteration at first:

• Show changeset bounding boxes on ZL 2-16 (*)
• Generate 1 tile layer with geometry for ZL 17
• Use that ZL17 tile layer to display geo on ZL 17, 18

(*) We would only show bounding boxes that impact the currently viewed area (so OWL would have to track what changesets impact what tiles for ZL 2-16).

I know this is aggressive, but I think it's a great first step to get up and running. More sophisticated viz on ZL 2-16 can always come later and can be based off of this first work.

Additional beauty of this approach is that the approach for ZL 2-16 can be extended down to ZL17 or 18 until geometry work is solid.

IMO, we would already have a huge step up from what's right now on openstreetmap.org with this approach.

/cc @zerebubuth @samanpwbb

[ppawel]

I'm not sure what would be useful at low zoom levels but I suspect that bounding boxes will get messy very quickly with a lot of data, even with clipping to current viewport.

Perhaps some mockups with data on it would help decide.

Example implementation of a "heat map": http://osmapa.pl/w/kody/

As for tile layers... my feeling is that having tiles at Z16 is a bit much - we could end up with a massive number of tiles. I was thinking more like Z14 and use them down to Z18 but I'm starting to think that this is asking too much of current browsers wrt vector rendering performance...

[lxbarth]

I'm not sure what would be useful at low zoom levels but I suspect that bounding boxes will get messy very quickly with a lot of data, even with clipping to current viewport.

I was assuming that we would always only show the latest N (e. g. 20) changes. Taking a look at the changesets we have on openstreetmap.org/browse/changesets right now this wouldn't get too messy.

Example implementation of a "heat map": http://osmapa.pl/w/kody/

Hm, interesting. I totally didn't think of a cluster map approach like this. What I like about it is that it makes lower ZL's much more useful. I don't know how we would deal with large bbox'es in this scenario though. There would be quite a bunch of clusters in the middle of the ocean for CS's like these.

I was thinking more like Z14 and use them down to Z18 but I'm starting to think that this is asking too much of current browsers wrt vector rendering performance...

Yes, this will be too much, 1 Z14 tile covers 256 Z18 tiles (4^4 = 16 * 16).

[ppawel]

The heat map would not be based on bounding boxes but on actual changes - each "heat tile" would have a number of changes associated with it.

[samanpwbb]

Here's a quick wire of how interaction could work on low zoom levels:

instead of showing individual changes in the sidebar, we show the clusters. Hover over a cluster to highlight it, either on the map or in the sidebar, click to zoom in.

[lxbarth]

Not sure how I feel about clustering changes, it introduces another concept that doesn't cleanly relate to changesets.

@samanpwbb's wires actually reflect what I'm worried about. On low zoom levels we would be talking about change clusters while on high zoom levels we would talk about changesets.

I guess one issue here is that it's unclear what lower zoom levels can actually be good for. A high level overview of how many changes we have in e. g. european countries like in @samanpwbb's wire is neat just like a visualization of all tweets mentioning #Sandy is neat. The higher zoom levels in comparison are much more powerful: They are an operational tool.

From this perspective, I'm thinking that a changeset centric approach to low ZL's would be preferable - it would mesh better with the actual useful output of this tool on ~ ZL16-18.

I'd also love to understand better of what's in OWL right now and what we could prop up fast for ZL1 to 15 to get us iterating. Maybe we should take this discussion into IRC.

FWIW, I could see us totally punt on this issue for an Alpha 1 (just like OWL) and see what we can do once we have the higher zoom levels up.

[samanpwbb]

@lxbarth I see binning changesets into clusters more as a UI for diving into relevant areas (rather than as an operational tool), allowing users to zoom out, look around, and dive back into high-activity areas quickly without ever being left in the dark. We just need to make sure we clearly differentiate the two listing types in the UI.

I agree that we should punt, but still as a UI paradigm this is exciting to me.

[ppawel]

Now at zoom levels 10 to 15 there are changeset bounding boxes.