Cache map data to speed up loading and reduce demand on iNat servers

Do we really need our distribution maps to be ‘real time’ all the time? How do people feel if instead we have instant distribution maps based on cached data? Then have an icon on the map showing date of the cache and next to it a ‘refresh’ icon. Clicking the refresh icon will then retrieve the ‘real time’ map data (i.e what we currently see). That info will then remain cached for all future views until someone requests a new refresh.

Reduce the load on the iNat servers.
Reduce the loading time the user experiences, esp users using iNat with a low bandwidth or in poor mobile data areas.

I suspect that most of the time when a user checks distribution maps, they don’t the latest information, and if they do, they can get still get it, so this feature doesn’t limit anyone’s experience of iNat.


Based on my experience it already is cached to some extent, but maybe could be more? In the scheme of the load on servers I would think taxon pages are pretty low. Not sure though.

Some related topics:


The maps take the most time to load on any page, and the taxon pages are terribly, terribly slow and I often can’t open them at all on the map tab. So I make sure they open on the taxonomy tab.

It’s not just the points on the map either, it is goog maps itself that is slow.

I like your idea very much, Vynbos. +1 vote for me (I’ve run out of votes). (Also, you have to vote for your own feature request by the by.)


I wonder if perhaps i’m asking for the wrong thing. Perhaps what i want is a screenshot of the distribution instead of a ‘live’ map . When I need to be able to zoom in and click on individual obs I can then opt to see the ‘live’ interactive map.
For example I have this bookmark I call 'empty obs.( it is the map of obs for a species with zero obs. I can then use it to zoom into the area i want to view. Once there I can click ‘redo search in map’ and only then change the taxon to something like ‘Asteraceae’. If i don’t do that, zooming in on the map to a small area with all the Asteraceae obs showing takes ages.
@karoopixie. Thanks but i’m also out of votes!

1 Like

I’ve noticed slowness in the map loading lately but it seems to be on google’s end not inat.

I personally wouldn’t want the maps any more cached than they already are though I’d be ok with not automatically loading coarse taxonomic maps like “plantae “


i don’t disagree with the gist of your request, but i think you’re asking for something that is not a small thing. it’s like i would like every person on earth to have 3 healthy and satisfying meals each day, but that’s no small thing.

it may help to understand what the map actually is. there’s the map container itself, along with all the fancy code needed to display the map. there’s a basemap layer that contains map image tiles in 8-bit .png format from Google. there’s a observation marker (circles or pins, depending on zoom level) layer that contains image tiles in 32-bit .png format from iNat. paired with the observation marker layer, there’s an invisible layer created from UTFgrid .json files, which allows the user to “interact” with the markers. there are taxon checklist place layers and taxon range layers that may also show up, depending on existence of such data. and finally, there’s an optional GBIF observation layer that pops up only if the user selects it.

the tiles in the map are displayed at 256px x 256px (Google) or 512px x 512px (iNat), and the page will pull only the tiles needed to fill the map container. so an average desktop screen might need 6 to 12 tiles per layer, depending on what’s shown. each Google basemap tile is relatively small – in the neighborhood of 10-30KB. the UTFgrids (tiles) are bigger – up to maybe 250KB, depending on how many observations they attempt to represent. the observation marker tiles can be even bigger – maybe up to 600KB+, depending on number of observations. part of why the observation marker tiles are so big is that they are oversized – 1024px x 1024px – which allows for better display on very high-resolution screens. The other part is that they are 32-bit .pngs (as opposed to Google’s 8-bit files).

now, it definitely does seem to take iNat’s servers some time to create / deliver the UTFgrids and observation tiles. you will definitely note that tiles with lots of observation markers take much longer to come back vs tiles with fewer observation markers.

it probably is technically possible to save copies of the observation markers, and i suppose, the matching UTFgrids, but that would require a significant rewrite of the whole mapping architecture, i would think. no small task. and while you might save the server a few ad hoc requests, you would instead force it to pre-query every possible set of combinations of possible queries (or at least queries for a certain set of parameter combinations) and to save all those tiles somewhere. i would guess that the taxon map is not so heavily used that doing this would make sense.

but there might be a couple of things that make sense. i would guess most people aren’t clicking on the maps to open up observations most of the time. so you could save on resources by not loading the UTFgrids unless specifically requested by the user. and you could also configure iNat’s servers to deliver 512px x 512px observation marker tiles that are actually 512px x 512px, which would make those tiles 25% as large. or you could at least make that configurable so that people don’t have to get the oversized tiles if they don’t want them. smaller 256px x 256px tiles might also help reduce the size of files that need to be delivered. and reduced bit depth might further reduce the size. these might not be small changes, but they probably would provide the most bang for the buck.


Yes, this would be the only viable approach. Google maps has a Static Maps API that can serve up snapshot images with markers. This could probably do most of what you want, but it has the major drawback that the entire specification for the snapshot has to fit in the parameters of a single url. The length of the url is limited to 8192 characters, so it severely restricts the number of markers that can be added. I suppose iNat could work around that limitation by using summary markers wherever there’s a high density of observations, rather than using one marker for every observation.

A solution like this would definitely have to be an explicit opt-in, rather than the default, since it would represent a quite significant downgrade for many users. Personally, I don’t have any problem with the current maps, and I would find it very annoying if I had to keep clicking a button (or whatever) to get the full version. For me, even the high density maps (e.g. all plants), usually only take about ten seconds to load - and I don’t have a very fast internet connection or a high-end PC.


Related: you can now test a new way of viewing map tiles, which should be faster than the current implementation: