All Observation Pins Overlaid on a Red Pin

This may be related to this post, but I’ve noticed it for a while so it might be something else.

When viewing the pin for an observation in that observation, it looks like it is sitting right on top of a red pin. You can see a little bit of red on either side of the bottom of the pin. This is mildly annoying because you have to zoom in really far just to make sure the pin you’re looking at isn’t just right next to another one. If you zoom in fast enough, sometimes you can see the red pin get “left behind” for a split second—and if it’s research grade you can see the white dot in the middle too (which you can’t see on the actual pin—perhaps a separate issue). This only happens in the actual observation, not in Explore, so it happens here but not here.


Yeah, I notice that too. I don’t think it’s a bug, but it’s still pretty annoying.

1 Like

Recently, I personally have been annoyed by all the red dots. I rationalize it is a good thing because the number of observations means more activity on iNat. However, I mostly use the maps to find the general area and topography of the place and a mass of red is not what I would like to see. Usually only use the dots for finding specific observations when there are only a very few in the area.

1 Like

there is a feature request to address this here:

I’ve been trying to locate some screenshots of old observation page maps to see if this has always been a problem, but no luck. so i’m not sure if what you’re describing is new or not…

i’ll get back to that, but first, let me describe generally how a map is structured, as i understand it. when you look at a map, you see a rectangle with a basemap and some markers on top. the basemap is delivered not as one image but as a bunch of smaller tiled images. as you pan the map, additional tiles are retrieved to fill in the places that come into view. (this tile approach prevents the system from having to either deliver one giant map image or constantly update the image to fit what’s shown in the map rectangle.)

you might think that the markers (ex. pins) are rendered as individual objects on the map, but they actually are delivered as image tiles, too. you can seemingly interact with individual markers because there’s another invisible UTFGrid tile layer tied to the marker layer that defines spots where some action (like clicking) can be taken. (the tile approach is used to display the markers because on some maps, there could be thousands or even millions of markers, and it could be very inefficient to try to send over and render on the client machine thousands of markers. it’s more reliable to send over tiled images of the markers instead.)

finally on the observation page (and i think also on the Identify page, and a few other places), the map there also has a larger marker that represents the specific observation referenced by the page. that marker is rendered as an individual object, not as part of a set of tiles (because there’s only one central observation on that map).

so right now, the big individual marker is basically replicating a marker that is part of an image tileset, and that’s why you see the “extra” marker. but think of what it would take to remove the “extra” marker. the system would basically have to dynamically generate a unique tileset that excludes a particular observation. technically that’s possible, but it is probably super inefficient.

for example, suppose you look at two different observations A and B that are near each other and are both identified to Dicot level. when you look at their respective observation pages, the maps right now can use the same Dicot marker tileset for both observations. however, if you exclude the “extra” marker, you’d have to generate 2 unique tilesets – one that is Dicots excl. A and another that is Dicots excl. B. not efficient.

i mentioned earlier that i was trying to figure out how the maps used to look. i suspect that in the past, the big markers were simply shifted down a little bit to cover the smaller corresponding tileset marker. that might have looked okay back in the day when the markers at higher zoom levels were relatively large circles. but now, the markers at higher zoom levels are smaller grid squares, and it might look odd if the large marker tip was landing below the area covered by the corresponding grid square.

now, let’s get to the reason you think the extra marker is annoying:

i don’t think this is necessarily the right logic. even if there’s just one pin there, that one pin could still represent multiple observations, if the multiple observations have (roughly) the same location. (in such a situation, the system appears to give you the details of the latest observation at that location if you click on it.) if you zoom in, sometimes you’ll notice that a single pin will be divided into multiple pins.

also, because the pin is so big, it could be hiding one or more small pins behind it even if you zoom in a lot. for example, look at this observation: if you click around, you’ll see there are multiple pins hiding behind the big pin. so you would still need to zoom in and out or click around to reveal those hidden pins anyway, and sometimes those hidden pins still don’t reveal that there are multiple observations there.

at the end of the day, i’m thinking this is all a minor annoyance, and maybe a better understanding of how things are structured allows you to look past it. ether way, i doubt this would be considered a bug.


Wow thanks for the explanation! Makes Intro to GIS seem like a walk in the park. I suppose then this technically wouldn’t be a bug then, but a feature request to change the code (although sometimes that’s what a bug report is)—probably very inefficient. Maybe fixing the color issue that they’re working on wouldn’t bug me so much. Many of the pins I look at are red anyway, and it doesn’t bother me there.

So, if I’m understanding this correctly, the “observation pin” is different from all the others (which might explain why it doesn’t have the research grade dot?). Would it be possible to make it slightly larger or the same size as the other pins? This wouldn’t eliminate the “zoom lag” but it would eliminate this:

Maybe it’s slightly transparent on the edges?

I suppose ultimately this is just me getting peeved by something insignificant but if there’s a relatively easy way to change it that would be nice. Otherwise it’s not that big of a deal.

if you’re talking about this:, then yes, i suppose if the big pin and little pin matched in color, they would look more like one thing. that said, you might want to chime in on that other topic to check on the status of it. one of the last posts there says an issue would be logged to address the observation page map, but i don’t see anything in Github, either at or

yes. that’s what it looks like to me.

that may be a question for the staff, and they’ll probably ask for a feature request to gauge interest from other community members first…

Sounds good.

Or perhaps another possibility: could it just not replicate so there’s only one pin to begin with?

I might not be understanding your explanation, but this sounds like it would be if it was trying to remove the underlying red pin. What if just didn’t show the observation pin on top? That sort of defeats the purpose of an observation pin if you can’t tell which one you’re trying to see—just brainstorming different options here.

1 Like

i think a compromise might be to have a larger marker but shape it so that it has a fatter base. right now, it’s sort of an upside-down teardrop shape, with a very tapered tip – acuminate, if i borrow from leaf morphology terms. if you made the tip more like an acute leaf tip – more like a true isosceles triangle topped with a half circle, or an ice-cream cone – then that would provide better coverage of items behind it. if you needed even greater coverage, then you could swap out the isosceles triangle cone of the ice cream cone with more of an upside-down house-shaped pentagon.


OK that seems logical. I’ll put in a request in a little while if the color issue isn’t resolved.

1 Like

As @pisum says - this appears to be working as intended / not really a bug per se