-
Notifications
You must be signed in to change notification settings - Fork 36
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
mask
fails when geometry encompasses raster
#816
Comments
This also causes zonal to fail, which is where I found this bug. If the geometry intersects but does not cover the raster, it works correctly. |
Yeah, that's a bug. Something wrong in the polygon burning algorithm |
Maybe Rasters.jl/src/methods/burning/edges.jl Lines 89 to 91 in 251bbbd
|
Trying to troubleshoot further. I can construct the Edges object manually after some sleuthing: allocs = Rasters._burning_allocs(raster; threaded = false)
Rasters.Edges(geom, dims(raster); allocs) which yields 2-element Rasters.Edges:
Rasters.Edge((-9.0, -9.0), 0.0, -8, 91)
Rasters.Edge((91.0, -9.0), 0.0, -8, 91) Not sure what this means though. The fields are: start :: Tuple{Float64, Float64}
gradient :: Float64
iystart :: Int32
iystop :: Int32 so iystart and iystop both appear to encompass the raster, and seem broadly correct as well. |
to dig in further, receptacle = fill(false, dims(raster))
Rasters._burn_polygon!(receptacle, geom; geomextent = GeoInterface.extent(geom))
receptacle yields julia> receptacle
╭────────────────────────╮
│ 11×11 DimArray{Bool,2} │
├────────────────────────┴─────────────────────────────────────────────────────────────────────────────────────────────── dims ┐
↓ X Sampled{Float64} 1.0:0.1:2.0 ForwardOrdered Regular Points,
→ Y Sampled{Float64} 1.0:0.1:2.0 ForwardOrdered Regular Points
└──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┘
↓ → 1.0 1.1 1.2 1.3 1.4 1.5 1.6 1.7 1.8 1.9 2.0
1.0 0 0 0 0 0 0 0 0 0 0 0
1.1 0 0 0 0 0 0 0 0 0 0 0
1.2 0 0 0 0 0 0 0 0 0 0 0
1.3 0 0 0 0 0 0 0 0 0 0 0
⋮ ⋮ ⋮
1.6 0 0 0 0 0 0 0 0 0 0 0
1.7 0 0 0 0 0 0 0 0 0 0 0
1.8 0 0 0 0 0 0 0 0 0 0 0
1.9 0 0 0 0 0 0 0 0 0 0 0
2.0 0 0 0 0 0 0 0 0 0 0 0 when it should presumably be filled with ones. |
Yeah, I'm guessing there is something wrong with the algorithm for this case, where it never hits a y crossing at all so it's never triggered to fill up the row with |
MWE:
that seems a bit strange?
Even rasterize has a similarly weird result:
The text was updated successfully, but these errors were encountered: