💡 [FEATURE REQUEST] Improved Default Zoom for all Kepler Maps

[alexbfree]

Paul pointed out that on maps (e.g. Uber, Google locations) the default view is scoped to show the whole world.

Instead, the map should zoom to something closer to the maximal extent of the points in the data.

It should take whichever is the smaller area of :

• that maximal area
• 200km around the top heard wifi access point location, if we have it

[alexbfree]

I need paul's input to help specific upon which point the 200km radius/rect is centred upon.

I'm thinking to find the centre we could do something like chop off 25% outliers that are most distant from the others and use mean average position of the remaining 75% points?

This will chop off holidays and short trips (which you identified as an issue) but i am not sure how well this will work for people who have data in two very disparate locations (e.g. people who have lived overseas like myself, data in both UK and Canada, don't want to end up centring on atlantic ocean centre)

[alexbfree]

Paul has clarified the centre point should be:

• Top heard wifi signal average => There is a tab that has wifi signals, for which we show the average location. That location.

Apparently this is different from average location, and can get around issues with someone who moved city. Will need to dig into code to understand how it works.

[pdehaye]

I meant my comment for Gmaps.

We didn't use Uber driver when doing the coaching session with client yesterday.

The ticket is formulated at the top with a different scope than what I intended:

• also Uber (so my suggestion not applicable, we don't have this data)
• all maps while some Kepler have to do with points, some with trips, and some with both (I meant for just the first tab of Gmaps which is where we experienced the problems, which might have been present elsewhere)

[alexbfree]

I think you are saying:

1. "narrow the scope of this ticket, we only need to change the default zoom for google maps first tab (places visited)" (plus potentially some others where we have default zoom issues, as yet not identified)

and

2. "for the "minimum of 200m from top heard wifi signal and max extent" rule, that can only be used in the case of google maps data where we have wifi data" -> so presumably that implies we just use maximal datapoint extents in any other case.

have i understood correctly?

If so, please provide additional detail how I can identify what other tabs 1. applies to.

[pdehaye]

In the current situation wait for a bug report?

The ideal would be that we could quickly identify all the experience tabs relying on kepler, then those that display points. (That ideal should not be pursued on its own. Many parallel tactical steps go in this direction, such as optimizing Uber driver for digipower live.)

Which makes me think: my Uber passenger is going to be subject to the same problem (I do airdrop around the world), and we should have my own data as a sample dataset and now I am tempted to put this in scope for the next digipower live (with home address removed).

[alexbfree]

In the current situation wait for a bug report?

No, not waiting for anything now. I can action this.

It's next up after #1092

Where you can help is to highlight places where you see issues with default zoom, as you notice them - just add them to this ticket (experience+tab+which dataset). Will be good to have multiple test scenarios.

[alexbfree]

BTW presumably since this is now focused scope on google maps that makes it lower priority than the Uber-centric stuff within #1087 that is needed for Thursday? If so I will drop priority to medium

[alexbfree]

Lowering priority as reasoned above, and removing from kepler/uber working set.

[alexbfree]

This is also on hold pending resolution of #1104

[alexbfree]

Given #1104 has no way forward, we have to find a work around for developing this (such as use of a local/test CDN URL, or using the Kepler standalone project).

[alexbfree]

Unassigned myself in case I don't get to this before going on leave and it needs advancing - but if it still here next week I will pick it up again.

[alexbfree]

putting this down to work on other things. Other people could pick it up if needed. ask me if any questions.

[alexbfree]

@pdehaye https://github.com/digipower-academy/private/issues/22 suggests this feature request should be reprioritised.

could you clarify whether this feature req is higher priority than directus work and how far you want us to go (e.g. do we do it for all experiences, do we do a fixed area (e.g. Europe) as suggested in linked ticket, or do we do it per the data (as described in this ticket above).

[pdehaye]

It's a higher priority for you to do this than Directus work.

[alexbfree]

Thanks, and any comment on scope/spec please?

[alexbfree]

I propose that the best sensible default for all maps might be this general algorithm:

(Desired result: whatever the data points, zoom to a level they are all 'in shot', 
with a small border around them so data is not right at the edge. All available 
data to take up about 7/8 of the available window, leaving 1/8 of width and height
at each edge as border).

1. Scan all data points and find max X, max Y, min X, min Y
2. Calculate Xspan (maxX-minX), Yspan (maxY-maxY)
3. Calculate midpointX ((maxX+minX)/2) and midpointY ((maxY+minY)/2)
4. Calculate xStep (=Xspan/6) and yStep (=Yspan/6)
5. Set view window coordinates to:
   - X extent goes from [midpointX-(4*xStep)] to [midpointX+(4*xStep)]
   - Y extent goes from [midpointY-(4*yStep)] to [midpointX+(4*yStep)]

I think this should give us a decent view for all datasets, whereever the points are in the world, with a view window just outside the extent of all available data.

[alexbfree]

I don't think the above algorithm is viable; the updateMap command for KeplerGL doesn't allow you to specify min & max viewport extents, instead it needs a centre, and a zoom level.

UPDATE: This is no longer correct so the rest of this comment can be disregarded.

---

old (ignore)

The zoom levels are a small integer (e.g. 9). These don't seem to be documented in KeplerGL docs but my working assumption is they are the same as Mapbox Zoom levels (since keplerGL uses Mapbox). On this basis the new strategy is:

1. Scan all data points and find max X, max Y, min X, min Y
2. Calculate midpointX ((maxX+minX)/2) and midpointY ((maxY+minY)/2)
3. Set viewport centre to midpointX, midpointY
4. Set viewport zoom level to 3 ( continent )

(from Mapbox docs:)

It's not ideal, because sometimes we may want city or country or earth level. Will review this option with team.

[alexbfree]

UPDATE:

After further investigation of https://github.com/digipower-academy/private/issues/22, i can now say categorically that :

• There is no default centring or zoom within the kepler compoonent.
• Many of our experience tabs do default to Geneva - but only if there is no locatable data - ie. no lat/long columns, not necessarily no rows, on the file(s) that the map tab in question reads from.
• If there is geolocatable data in the data for the specific tab where the kepler map is, Kepler handles the centring of the map automatically base on the passed in data, and this is working correctly in all cases I have tested.

Therefore, there is nothing to do here and I will close this feature request.

The only open question is what to do about default behaviour when there is no geodata.

Options include:

a) hide the map and only show the table - because there is nothing to show
b) zoom to Geneva
c) zoom to whole continent of Europe (or some other place? whole world?)
d) look at data across all tabs, figure out centre & zoom base on that.
e) have a configuration option per bubble/deployment which allows a default zoom location/zoom level to be specified
f) it doesn't matter, we don't even care about this scenario, now we know what is happening, we can just explain it's due to no geodata.
g) some other behaviour.

This can be handled as part of ticket https://github.com/digipower-academy/private/issues/22

BTW, if we ever do need an improved zoom, I checked in some code on default-zoom-enhancement branch that may be useful. But i think Kepler default behaviour is good enough and this branch can be ignored/archived/deleted.