Open test of map tile improvements

This issue has now been fixed. If you have opted in to the map tile test you can now see separate colors for separate taxa.

3 Likes

I just opted in, and I like it! The first item below was my immediate reaction and the second is a suggestion after reading the discussions above.

  1. Keep the square color consistent with iconic taxon color (i.e. green for plants, etc.)
  2. Because this will cause difficulty for colorblind folks and for single observations, give each square an opaque white border so that each square can be seen regardless of color or saturation. This may not end up looking as pretty, but it might be a worthwhile compromise.
3 Likes

If this is ugly for others but helps for colorblind people, it could always be made into a preference.

4 Likes

I believe this was how the test started out – the tiles were show in various densities of the color of the relevant iconic taxon, so plants were indeed shown in green. A lot of testers (myself included) reported problems seeing the tiles against either the satellite or map backgrounds. The response was to use orange consistently for single-taxon maps, presumably because orange stands out quite well against most backgrounds. I think that adds a lot more than is lost by not having different colors for different kingdoms and phylums.

My preference would be that the core design should work well for most accessibility requirements. If there’s a design choice that improves accessibility for some users (e.g. for a particular type of color blindness) but reduces it for others, a user preference would be a great way to handle that.

5 Likes

Thanks to everyone that has opted-in and given feedback on these grid tiles. We’ve made a few changes based on your feedback. Here are a few of the changes we made:

  • The grids are now the same color (orange) in all cases. Using different colors based on iconic taxon wasn’t working out due to inconsistent visibility on the “map” and “satellite” style of map, and some colors such as green didn’t work well in most cases. Using a consistent color seems to maximize visibility of the grids across various views. The compare tool will continue to use different colors (not iconic taxon colors) to represent different taxa
  • The minimum opacity was increased, meaning the least-dense cells are now a little darker and easier to see
  • The opacity of the grid boundaries was also increased, which should further make isolated grid cells more visible. The boundaries can fade a little when cells are tightly packed together, and this seems to enhance the visibility at a glance of high-density regions
  • The heatmap view was updated to use a similar query to what is used to generate the grids, but to use heatmap-like colors to represent observation density.

We think it’s time to swap over to the new grid tiles completely for all users. We can continue to tweak styles as needed after the switch. If anyone feels strongly that it is not a good idea to make the switch now, please let us know why.

A few questions came up that I should respond so:

This is the same behavior as with the existing circles. There is a geo-aggregation happening behind the scenes, and a single box or circle (or point when zoomed-in) can represent many observations. We chose to have the popup info window only display the most recent observation in that cell, but it would be possible to link that to an observation search or something. The cell may represent millions of observations, so probably best to link out to a search rather than attempt to list them all in the tiny info window.

The idea is to entirely replace the circles with the grids, at least on the website and mobile apps. The API will continue to support the older styles, but it’s likely those will eventually be deprecated if the current version of the API is deprecated.

This is on the observation details page. The issue at hand here is cacheability. I agree it would be ideal to not have the current observation have both a pin and grid. The problem is, in order to do this, we need to send an additional parameter to the map tile API that says to exclude this observation.

Imagine for example 10 observations in roughly the same place all at taxon Plantae. If we just request the default Plantae tiles, we could cache the tiles after the first request and re-serve them for subsequent requests. But if we add the “not this observation” parameter, then the tiles are only relevant to the given observation and need to be regenerated for each observation separately, incurring a computation cost, which is especially high when the observation taxon is broad and has many observations.

There may be ways around this, for example to know which cell the observation will appear in and to re-generate data for that one cell but allow use of the cached versions of map tiles for that taxon in other cells. But since that is not in place right now, I’d expect to launch as is, and to fix this issue at some point in the future.

This is unfortunate, and we have some options to address this, but each would be pretty different than what is there now. We are using a V1 of the GBIF maps API for those red/purple squares and that API version is now deprecated. One thing we were able to do with it was customize the colors and opacities of the GBIF squares, and that is no longer possible (the style we use is still available but it can no longer be customized).

We could continue to use the V1 API and use the default yellow/orange GBIF colors (e.g. https://api.gbif.org/v1/map/density/tile?x=4&y=6&z=4&type=TAXON&key=5133088&resolution=4), but these are still quite similar to our orange. Or we could use the V2 maps API from GBIF (https://www.gbif.org/developer/maps) and one of their pre-defined styles. It doesn’t look like the V2 map tile opacity can be customized, so we’d either need to use the *.point styles they offer, which render very small dots, or one of the *.poly or *.marker tiles which would often cover up the iNaturalist grids. Any preferences among those options?

7 Likes

i actually quite like GBIF’s .point styled markers, especially the purple/yellow one. i haven’t mocked it up to see how it looks with the new iNat grids. so i might still change my mind about that later.

1 Like

ok… i’ve already changed my mind after doing a bit of testing. i think the points are probably too small when there are few observations/occurrences. so a small poly (square at, say, size 32 or maybe a similarly small hex) is probably better for visibility. i like either the purple/yellow and iNaturalist poly color schemes.

https://api.gbif.org/v2/map/occurrence/density/{z}/{x}/{y}@1x.png?bin=square&squareSize=32&srs=EPSG:3857&style=iNaturalist.poly

https://api.gbif.org/v2/map/occurrence/density/{z}/{x}/{y}@1x.png?bin=hex&hexPerTile=64&srs=EPSG:3857&style=purpleYellow.poly

i don’t know how difficult it would be to do this with the Google mapping framework, but i think you might be able to use CSS styling to modify the opacity and colors of the GBIF tiles. here’s an example where i took some black and white Stamen basemaps and used some CSS color filters to make them green and black: https://jumear.github.io/stirfry/iNat_UTFgrid_based_custom_density_map.html?example=4. i’ve seen plugins in Leaflet that allow you to do something similar in concept. not sure about Google’s mapping platform.

2 Likes

I would like to have obscured observations displayed in a way their status is easily recognized. Zooming in, the red squares eventually will turn into the ‘old’ obscured circles, but further away, these squares indicate a wrong location of the observation.

3 Likes

I agree, maybe those could be a different color or only depicted as a big square the size of their uncertainty/obscuring buffer. Maybe that would be visually jarring but, it’s a pain how they display in ‘wrong’ locations.

Or possibly just a feature to toggle them on and off so one could look at ‘clean’ range maps (at least of species that don’t auto-obscure).

3 Likes

Here’s a map that helps depict the issue: all of these observations were observed within the large, light orange place, but the obscured obs are appearing to the north in dark orange:

image

(It’s a county, a standard place, so the “obscured obs radius breaks the place border so it doesn’t appear in the place” rule doesn’t apply)

3 Likes

The issue with obscured observations isn’t new with these grids, right? If you opt-out of the test, does the same issue exist with the old circle style of high-level maps? If so, my preference would to continue with the plan of rolling out these grids as a replacement for the older circle style and address issues of mapping obscured observations separately. Sounds like it warrant its own forum topic.

1 Like

It’s not a new problem, other than that style change from “light grey and large circle” to “dark orange and small square” makes the existing issue a lot more salient. It’s obviously not worth stopping the swap to the new maps, but since you were talking color/style options, worth bringing up. @carnifex (or @charlie?) if you want to mock up what an improved map of obscured observations would look like, you can create a topic in #feature-requests we can move the discussion there.

2 Likes

It’s very nice and usefull feature, but I’m missing the scale of squares (it will be nice to know the length of the square.

PS: It’s also strange that if I click on the square I get some single observation. Shouldn’t it be unclickable at all?

The maps have become desperately slow. I can add an ID, an annotation and a project to an observation, and the map has still not appeared by the time I’m done.

Also the pins/squares come up first, and the map last. On places with many observations, this means I cannot actually see the map at all (once it does load) because the pins/squares are already there. Would it be possible to load the map layer before the pin layer? And would it be possible to speed up the map loading time?

3 Likes

I’m not sure if this is a separate issue or related to the map changes, but the bug where if you open an unknown record from the identify screen and open it in the popup view, after adding an ID, the map does not refresh with pins of related records is back.

This got broken and was fixed a while ago, but is now back.

1 Like

Is this consistent, @karoopixie?

Yes, Tony.

1 Like

i don’t think anyone has commented on the new heatmap since it was still in early development. so i’ll just chime in here and say that the new heatmap looks to me like a vast improvement on the old one. specifically, it looks consistently good/useful at different zoom levels. so i’m looking forward to seeing this go out to the masses.

7 Likes

@pleary – i noticed one minor thing. when you click on a grid cell, it opens a pop-up for an observation (the latest one in that cell?). that’s fine, but i think the area that you click on to trigger the pop-up is actually offset slightly down a few pixels vs the cell. (i noticed this behavior because i had a situation where there was a cell just above another cell, and clicking on either cell seemed to trigger the same pop-up corresponding to the upper cell. i had to click on the bottom half of the bottom cell or a few pixels below it to trigger its pop-up.)

UPDATE: i mocked it up with UTFGrid in green on top of the geotile grid, and it looks like a cell from the geotile grid actually gets represented as 5 one-fourth size cells arranged in a plus sign, instead of 4 one-fourth size cells arranged in a square to match the original cell. i think that’s why i can click below the cell and trigger an action, and i can also click to the right of the cell an also trigger an action.

i think there’s always been a bit of a mismatch between the markers and the UTFGrid representation, but it’s particularly noticeable in the new grid because it’s a grid without overlapping markers.

2 Likes

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.