[BUG] Map.fly_to raises if you pass a numpy.int64 for zoom

[shawnboltz]

Context

I called Map.fly_to and passed a value for zoom that was a numpy.int64.

Resulting behaviour, error message or logs

A type error got raised because of the numpy.int64. The type checking in the fly_to is overly restrictive and explicitly checks for a normal int or float:

if not isinstance(zoom, (int, float)):
    raise TypeError(f"Expected zoom to be an int or float, got {type(zoom)}")

I recommend instead trying to cast the value for zoom (and latitude and longitude) to floats and only raising if that fails.

Environment

• OS: Windows 11
• Browser: Firefox
• Lonboard Version: 0.12.1 (though I see it's still present in 0.13.0)

Steps to reproduce the bug

import geopandas as gpd
import numpy as np
from shapely.geometry import Point

import lonboard

d = {'col1': ['name1', 'name2'], 'geometry': [Point(1, 2), Point(2, 1)]}
gdf = gpd.GeoDataFrame(d, crs="EPSG:4326")
layer = lonboard.ScatterplotLayer.from_geopandas(gdf)
map_ = lonboard.Map(layers=[layer])

map_.fly_to(longitude=0, latitude=0, zoom=np.int64(2))

Thank you for all of your efforts on lonboard. This library has been extremely helpful for a project that I'm currently working on that involves plotting large shapefiles.

[kylebarron]

Thanks for the issue!

Hmm. I'm somewhat lukewarm on this. I don't know whether it should be the responsibility of the library to cast to a Python float.

Do you know how the float constructor works? Are there any potential pitfalls of trying to cast the input to a float?

For example, if we just blindly try to cast any input to a float, then that also permits string input, which I don't want to allow:

[shawnboltz]

Thanks for your response. I understand your hesitance, particularly if you do a lot of programming in other languages where types are more strict. I debated whether to open the issue, especially because it's easy enough for the user to just cast their input to a float first. But because this library interfaces with GeoPandas, which relies on pandas and numpy, I thought it was worth pointing out. These libraries have a lot of things that are number-like but will fail against an instance(x, (int, float)) check. Their custom number types are a blessing and a curse because they allow for much higher precision than the built-in int and float at the cost of making type-checking a nightmare.

You are correct that float("3.14") would successfully cast "3.14" to a float, which may not be intended. But if any object that isn't float-like gets passed to it then it will just raise a ValueError:

In [2]: float("a")
---------------------------------------------------------------------------
ValueError                                Traceback (most recent call last)
Cell In[2], line 1
----> 1 float("a")

ValueError: could not convert string to float: 'a'

There is one other scenario I can think of where this might cause strange behavior, but it's worth pointing out that this will already pass through the isinstance(x, int) check:

In [3]: float(True)
Out[3]: 1.0

Another alternative that I just came across that would probably be safer is to add numpy.floating and numpy.integer to your isinstance checks, which would then allow most, if not all, of those number-like types:

In [24]: def isnumeric(x):
    ...:     return isinstance(x, (float, int, np.floating, np.integer))
    ...: 

In [25]: isnumeric("a")
Out[25]: False

In [26]: isnumeric("1")
Out[26]: False

In [27]: isnumeric(1)
Out[27]: True

In [28]: isnumeric(1.1)
Out[28]: True

In [29]: isnumeric(np.float64(2.12))
Out[29]: True

In [30]: isnumeric(np.int32(1234))
Out[30]: True

In [31]: isnumeric(True)  # This one is a 'gotcha' because isinstance(True, int) returns True
Out[31]: True

[ATL2001]

I've never run into this issue with lonboard, but I have with a few other python packages. I've always worked around the errors by just tacking on a .item() in my code when I was expecting a numpy number to convert it to a python scalar ( I type this with lots of numpy love whilst wearing my numpy hoodie 😄) .

import numpy as np
np_float = np.float64(100)
np_float.item()

[kylebarron]

I think perhaps it makes sense to special-case support for np.integer and np.float because other parts of the Lonboard API are explicitly numpy-aware.

[kylebarron]

Would you like to make a PR for this? You can put the handling in the trait validation

[shawnboltz]

Would you like to make a PR for this? You can put the handling in the trait validation

Sure, I can take that on.

[kylebarron]

Maybe just here

lonboard/lonboard/_map.py

Line 635 in cf8259c

if not isinstance(longitude, (int, float)):

add an

if isinstance(longitude, np.numeric):
    longitude = float(longitude)
if isinstance(latitude, np.numeric):
    latitude = float(latitude)

plus a test