Map off-center - Lithobates pipiens

#1

In testing new code that was added for a map command for the Discord bot today, we discovered one taxon that is off-center, Lithobates pipiens.

You can see this on the web here:

https://www.inaturalist.org/taxa/66003-Lithobates-pipiens

Click on the Maps tab and you’ll find the center is in the middle of the Pacific Ocean. Is this a bug, or a problem with the data? There doesn’t seem to be any observation out there, but maybe it’s obscured?

Thanks,
Ben

P.S.

I’d like to give a word of thanks to our new contributor, @nadando (on Discord), who provided the code for a new /map command for our bot. Thanks to his contribution, we can now construct range & observation maps for one or more taxa with a simple command:

,map northern leopard frog, southern leopard frog, plains leopard frog, rio leopard frog

which produces maps like this:

image

Range map for Lithobates pipiens, Lithobates sphenocephalus, Lithobates blairi, Lithobates berlandieri

It was in testing this new code that we hit the oddness with the one off-center taxon. In the example above, you can see how that one off-center taxon affects the whole map. You have to pan the map over before you can see the observations & ranges of the plot.

1 Like
#2

there’s a wayward observation in NW Thailand that doesn’t show up as a point the map for some reason. i didn’t spend the time to figure out what’s going on exactly, but this is the observation: https://www.inaturalist.org/observations/8310049

… and this is how i found it:
https://www.inaturalist.org/observations?place_id=any&taxon_id=66003&id=32244904&swlat=18.788486402481794&swlng=98.84197301231325&nelat=18.788486402481794&nelng=98.84197301231325

1 Like
#3

My maps are all centred on the Pacific Ocean. Despite setting it to Southern Africa.

#4

It’s good to know there’s a reason for it. Has it been discussed before whether something can or should be done about hidden/unconfirmed observations skewing the bounds returned by /v1/observations?

I suppose if I started building out the map query grammar, I could have it support:

/map taxon1,taxon2,... from location1,location2,...

Where the keyword “from” indicates that one or more locations separated by keywords follow. Then if the user notices the map is off-center, they could redo the query with the “from” filter to recenter the map.

Or … back to the usual use case, a user would simply recenter the map (which is what the above would accomplish, though additionally it would filter the observations).

#5

personally, i think the bounds skewing is fine if the observation is legitimate. the observation here wasn’t hidden exactly. (it wasn’t obscured nor private.) it just didn’t show up on the map for whatever reason. i’ve seen cases like that before, and it’s possible that it’s just been fixed. see https://forum.inaturalist.org/t/map-does-not-show-all-points-for-a-species/2305.

that said, this particular observation seems to have had its photo flagged and removed. so it’s now a casual observation and should no longer skew the map.

if you’re building your map thing based on the iNat Range Map thing you referenced in your original post, then i think your “from” clause would need to reference a single center point (or a bounding box that you would determine the center point for) and a zoom level. i’m not sure why you would need multiple locations.

if you’re intending to filter the observations by location, then that’s another thing, but then that would probably require that you have a lot more of your own code to support that kind of filter. (that’s the way i would have built it, but i don’t think it’s a quick thing to do if you haven’t already done it.)

#6

We use /v1/observations get the total_bounds for all taxa in the query and compute a center point and zoom level.

The proposed from clause would just find places via /v1/places/autocomplete to pass as a comma-delimited list to the place_id argument of the /v1/observations call. The map would then just show the subset of observations in the area of interest, and the center point would no longer wander out into the middle of nowhere.

#7

ok… so it sounds like maybe you guys are doing something more complicated with your map thing than just using the straight iNat taxon map.

i get that you would use the observation endpoint to get total bounds, but do you mean that you’re also passing the place_id to an observation tileset + UTFGrid to limit the observations that show up on the map?

#8

Ah, no, actually, just passing in the taxa=#,# on the URL, now that I look at it, though we do use /v1/observations for those same taxa to get the bounds, and that could be limited to an area as I proposed. So I retract what I said above: it would limit the size of the viewport on the observations but wouldn’t actually take those observations off of the map. That might be sufficiently confusing that I shouldn’t implement it that way, as elsewhere, I’d want ‘from’ to actually limit observations to those locations. I could, however, use some other keyword to indicate the center/zoom are being recomputed for the specified place(s).