Map filters don't show valid values in some cases

[runxc1]

Describe the bug

On the Pin Map Visualization I have over a thousand pins all over the world so in order to see the details you have to use the "draw box to filter" functionality to get proper pins with details.

If you select a box in the australia area you get a bogus latitude/longitude area.

To Reproduce

1. Go to Pin Map visualization of the world

2. Click on Draw box to filter

3. Select an area in Australia and get a result that looks like the following

4. latitude is between -15.948376882697627 and -9.788770636626007 and longitude is between -234.51114320954838 and -221.0616648849495

5. Observe that longitude is less than -180 which is the lowest the scale should go

6. A Valid lat,long in australia as an example is -12.46, 130.84

7. See error as no results

Expected behavior

It should show the area selected

Logs

NA

Information about your Metabase installation

docker metabase:latests

Severity

blocking adoption in an organization

Additional context

Probably a simple math error due to only testing in the US and Europe. Probably should add additional data points to the Sample data.

[paoliniluis]

Hi, I just tested and got the correct lat lon

can you upload a video so we can see what you're hitting?

[runxc1]

Here is a video, I just created a visualization off of the Sample data.

https://screenrec.com/share/igTGbjw5xh

[ignacio-mb]

@runxc1 Can you provide some sample data for Australia so we can reproduce your error?

[ranquild]

I'm not 100% sure if this is it but here is my attempt to reproduce the issue.

1. Create a SQL query:

   SELECT 1 AS COUNT, -30 AS LATITUDE, 179 AS LONGITUDE
   UNION ALL
   SELECT 1 AS COUNT, -30 AS LATITUDE, -179 AS LONGITUDE

2. Visualize as Pin map

3. See that -179 and 179 are on the different sides of the map

   

4. Draw a box to filter the values. Each time it works based on what you see on this map, e.g. you only get values for one of the sides without correct semantics:

   

Filters with longitude outside of -180,180 range prove this. I think what we might want to do instead is to flip values less than -180 to 180 and wise versa. If this makes sense, then Lib.updateLatLonFilter MBQL lib function could be updated to hide this complexity; most likely 2 filters instead of 1 need to be created for these cases.