Adjust dot size with zoom level

[quasipedia]

The size of the dots in a Tile Map should be "human-friendly".

I did not inspect the code, but I am under the impression the max size of a circle, when selecting scaled circle markers is bound to the size of the underlying geohash_grid cell. This is sensible in theory, but in practice this does not work with zooming. A few screen-grab (precision 1, 3 and 7 at exactly the same zoom level) should exemplify the problem:

The problem is many-folded, IMO:

1. At medium-high level of precision it's hard to even spot the dots
2. At medium-high level of precision the difference in circle size is so tiny that it's impossible to apprecaite where the bulk of the data comes from
3. Ad different precision levels the total surface of markers is hugely different, despite representing the same quantity

I'd rather prefer the markers to overlap (one can zoom-in to decouple them, if needed) as in any of these two examples:

[rashidkpc]

An excellent point, I see you've also commented on #2034 too. I think we could improve the behavior here even before implementing #2034

[jmleoni]

+1

[macolu]

+1 !

[rashidkpc]

@jthomassie Is this issue similar to any of the ones you entered today?

[jthomassie]

@rashidkpc yes, this is somewhat related to #3159 and #3161, and it is a bit complicated to explain.

Precision 7 markers can not be appreciated at a map zoom in the examples above. The markers ideally represent a diameter of 155m or 500ft at that precision, probably much more precise than the original data.

• This is an inherent challenge with geohash grids. Going up in precision creates much smaller geohash grid areas and typically reduces bucket counts for each point/marker.

• If the original lat/long data is precise enough to warrant a geohash precision of 7, then you must zoom in to see that level of precision on a map, and the markers should not be much bigger than that area or they will completely obscure each other.

• If the original lat/long data is NOT that precise, increasing the precision on the map tends to 'hide' the data by putting similar bucket counts into smaller and smaller geohash grid areas (represented by smaller markers).

• Circles are very poor representations of geohash grids because the area of each grid rectangle varies dramatically depending on the latitude, due to distortion of a cartesian grid on a sphere. Some grid areas are very horizontal and some are very vertical, so fitting circle markers to the grid is very imprecise. Rectangles are much better -- they precisely show the actual grid area.

• So, to put markers for geohash grids on a map, we need to use either rectangles of the actual area or circle markers that is fit the ideal area (at the equator):
precision 1 = about 5000km/3100mi max diameter
precision 2 = about 630km/390mi max diameter
precision 3 = about 160km/100mi max diameter
precision 4 = about 20km/12.4mi max diameter
precision 5 = about 5km/3mi max diameter
precision 6 = about 615m/2000ft max diameter
precision 7 = about 155m/500ft max diameter
precision 8 = about 20m/65ft max diameter

• Most of the time, the original lat/long data does not warrant a precision higher than 5 or 6 or maybe 7. In my experience, it is rare that lat/longs are at 20m or less apart.

See elasticsearch geohash grid aggregation explanation:
http://www.elasticsearch.org/guide/en/elasticsearch/reference/current/search-aggregations-bucket-geohashgrid-aggregation.html#_cell_dimensions_at_the_equator

[jthomassie]

Here is some US data for places (cities, towns, places, etc.). The ideal precision to view this is on a map is between about 3 and maybe 4 or 5. (Precision 6 is 2000ft apart, and towns are not that close to each other).
• Selecting precision higher than 5 does not create more detail in the data. Buckets disappear (no towns) and most buckets have very low counts (1 or 2 towns)
• Selecting lower than 3 tends to misrepresent data. Areas are so large, they lose meaning for a collection of towns and cities.

(I modified 'Shaded Circles Markers' to show rectangles for this demo. Note shapes and sizes of the geohash grid rectangles as precision changes)

Map zoom 3, precision 1

Map zoom 4, precision 2

Map zoom 6, precision 3

Map zoom 8, precision 4

Map zoom 9, precision 5

[quasipedia]

@jthomassie - Concerning:

Circles are very poor representations of geohash grids because the area of each grid rectangle varies dramatically depending on the latitude, due to distortion of a cartesian grid on a sphere. Some grid areas are very horizontal and some are very vertical, so fitting circle markers to the grid is very imprecise. Rectangles are much better -- they precisely show the actual grid area

While I see where you are coming from, I believe your statement makes a number of assumptions that are not really true or general enough.

• Currently in Kibana one can choose to either represent data "count" as a shade of colour or as a circle radius. The two cases are really different ones.
• Despite the system working on a grid, at a certain level of precision - and depending on the type of data you have - you can consider each cell as a point. For example, if you use the system to locate cities, it really doesn't matter if the underlying cell is 3 squared centimeters or 10.000 squared metres in area. There will only ever be 1 city per cell, maximum.
• Rectangles absolutely do not show the "actual grid area". They show the "projected grid area" of the bi-dimensional approximate representation of a sphere. In the case of Marcator projection (the one currently in use on Kibana) your assumption is particularly wrong. For it to be true, one should use the Gall-Peters projection or any of the other equal-area ones.
• Sometimes you may use the map as a "heatmap" (where data density is relevant), sometimes you will use it to locate individual "things".
• In the case of heatmaps with colour shades, using rectangles would be very intensive, as one should assign the colour of a cell not according to the total count of data points, but to that number divided by the actual surface of the cell IRL, and then possibly adjusted for the distorsion of the map projection.

Bottom-line: while I see your point and your user case, I think it would be a poor choice to swap circles for rectangles. Rectangles should absolutely be one of the alternatives (I would appreciate a simple "pin marker" too, if possible then), though.

[jthomassie]

@quasipedia We use leaflet.js and mapquest tiles, so Mercator projection is our only option. That is standard for most, if not all tile map libraries.

We're planning several tilemap enhancements that address some of your comments:
• improving the sizing of circles to better fit the projected geohash grid area
• adding a rectangle option
• adding a heatmap option
• adding a marker cluster option (which will allow you to zoom in to see pins)

[quasipedia]

@jthomassie - Thank you for the quick reply!

AFAIK, Mapnik has support for non-marcator tiles out of the box, and leaflet.js has support for custom projections too (although IIRC none of those provided as "examples" are equal-areas ones).

That said, an equal-area projection would most definitively be towards the bottom of my wish list for Kibana (I'm happy with Marcator for the type of data I use). For reference if somebody would like to give it a go, here's a pair of articles that show how that could be achieved:

• Leflets and custom projection
• Mapnik and equal-area tiles