One other follow-up issue on #1251, is about what to do in nearest() in case of missing/empty input geometry (original comment from @caspervdw here: #1251 (comment))
Currently we raise in this case:
>>> points = shapely.points(range(5), range(5))
>>> tree = shapely.STRtree(points)
# normal behaviour with input geometries
>>> tree.nearest_item(shapely.points(1.5, 1.5))
1
>>> tree.nearest_item([shapely.Point(1.5, 1.5), shapely.Point(3.5, 3.5)])
array([1, 3])
# if one of the input geometries is missing or empty, we raise an error:
>>> tree.nearest_item([None])
...
ValueError: Cannot determine nearest geometry for empty geometry or missing value (None).
>>> tree.nearest_item(shapely.Geometry("POINT EMPTY"))
...
ValueError: Cannot determine nearest geometry for empty geometry or missing value (None).
An alternative option would be to return "max_index + 1" (so an out of bounds index for the original tree geometries).
Some more argumentation about this at #1251 (comment):
[Casper] I had one proposal for “nearest” in the case of missing inputs or trees. Instead of raising directly, you could also return an index that is out of bounds (latest + 1)
This happens also for instance when using “np.searchsorted”.
[Joris] I think for the "nearest" purpose, that might be annoying to work with afterwards. You could typically use the return value as an index to get the corresponding geometry (or attributes corresponding to that geometry), and then an out of bounds index will error (so you would also have to explicitly check for that).
[Casper] True, but getting an error or a None (unexpected return type) would also be annoying. Returning index + 1 does give the additional option to substitute those values with None / NaN when transforming indices to geometries. In that way, None input may result in None output when querying the tree for nearest geometries.
One other follow-up issue on #1251, is about what to do in
nearest()in case of missing/empty input geometry (original comment from @caspervdw here: #1251 (comment))Currently we raise in this case:
An alternative option would be to return "max_index + 1" (so an out of bounds index for the original tree geometries).
Some more argumentation about this at #1251 (comment):