https://www.inaturalist.org/taxa/map?taxa=74191,74190,68137,74189,74188,43523#5/5.791/41.797
5 Likes
Wow! How did I not know you could do this? Thanks @tonyrebelo!
1 Like
Do you think we could get rid of the grid square representing the current observation and just keep the pin? I often find that I can’t tell whether there are two observation in an area (the current plus another), or just the current one.
3 Likes
Just noticed today that the tiling system has changed and it is now much easier to find single obs tiles. Seems that only orange is used, and individual obs in the identotron are solid orange.
1 Like
Yes, it is an improvement.
However, I just found out that when multiple taxa are displayed simultaneously, they are now all shown in the same color.
Before:
Now:
6 Likes
That’s not good news
2 Likes
Yes, the change to display all tiles in orange breaks the “compare” and “taxa map” functionality.
I’m hoping that iNat can use taxa-specific colors in those multi-taxon contexts while still maximizing visibility of observations in single-taxon contexts.
1 Like
Thanks folks, we’ll fix the compare tool
9 Likes
Please note that the current red tiles is too similar a shade to the GBIF data points, so that one cannot see the GBIF localities when one activates the layer. Would be nice to have them more different!
3 Likes
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.
- Keep the square color consistent with iconic taxon color (i.e. green for plants, etc.)
- 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.
5 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.
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:
(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