-
Notifications
You must be signed in to change notification settings - Fork 3
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
skip NaN in union and intersection #30
base: main
Are you sure you want to change the base?
Conversation
Hmm maybe this is wrong... if there is any NaN in an extent maybe the whole thing should be throw out? Currently this just throws out the individual NaN |
Hmm I'm not sure there. It's not even that throwing out the extent is the safer option, since it means the spatial dimension is constrained to the non-NaN extent... |
Yeah I think youre right, we just keep non-nan and thats as good as it can be, there are problems either way |
Also is this breaking? I feel like its a pretty grey area, nan bounds are just undefined behaviour, and we can change undefined behaviour |
I wouldn't call this breaking for exactly that reason |
@evetion would be good to get your perspective on if this makes sense |
I'm unsure about this, it's a grey area to be sure, and one might handle the spatial/non-spatial cases differently. NaN spatially is akin to a missing coordinate. We have a skipmissing for that matter, so for calculating extents, skipping nan makes sense. However, if the nan ends up in an extent, it implies there was only a single coordinate (or none) in that dimensions. I'd say we error out, because there's no (or an unknown) extent in that dimension then. Spatially, X and Y are intertwined, so an XY Extent that has a NaN is useless in the sense that most spatial operations (intersect, etc) can't work. If you're only interested in a single dimension, probably non-spatial, I guess one could handle it, but I would write down some use cases before implementing it, as most of the downstream behaviour is undefined. Besides, in this PR the following snippet is unrealistic: TLDR: I don't think this makes sense, except for skipping nan numbers (akin to skipmissing) in calculating extents. |
The thing is
Currently NaN pass through and returns NaN for lower or upper whichever was NaN but not both. So erroring really would be a breaking change. Are you suggesting To clarify this PR is making the minimum possible changes that reduce NaN propagation without much of a performance hit or breaking some behaviour |
Sister PR to JuliaGeo/GeoInterface.jl#166
@asinghvi17