JuliaGeo / GeometryOps.jl

GeoInterface-based geometry operations
https://juliageo.org/GeometryOps.jl/
MIT License
29 stars 4 forks source link

Polygonize example is broken #187

Open ConnectedSystems opened 3 months ago

ConnectedSystems commented 3 months ago

Trying out the example here: https://juliageo.org/GeometryOps.jl/stable/source/methods/polygonize#Polygonizing-raster-data

Results in an error

julia> using GeometryOps, GLMakie, GeoMakie

julia> n = 49
49

julia> xs, ys = LinRange(-3, 3, n), LinRange(-3, 3, n);

julia> zs = Makie.peaks(n);

julia> polygons = polygonize(xs, ys, 0.8 .< zs .< 3.2)
ERROR: MethodError: no method matching similar(::Type{Vector{Tuple{Float64, Float64}}}, ::LinRange{Float64, Int64})
rafaqz commented 3 months ago

This is likely getting through tests because we test against OffsetArrays.jl and it pirates similar

https://github.com/JuliaArrays/OffsetArrays.jl/issues/306

I think I've fixed it for poligonize in the testing PR that has taken forever to be merged.

But @jishnub this keeps happening. For the time being we will stop testing against OffsetArrays.jl, it's just not suitable to use in tests.

jishnub commented 3 months ago

I'm unsure if I understand the issue here. OffsetArrays defines similar for AbstractUnitRange axes, so a call with LinRange as axes should fail anyway? Does this pass tests with OffsetArrays loaded?

rafaqz commented 3 months ago

It's possible not with this exact range but we've had multiple problems and hacks around it already

asinghvi17 commented 3 months ago

I don't think this is an OffsetArrays issue in this particular case.

rafaqz commented 3 months ago

I think the issue is the code is the way it is to avoid another OffsetArrays.jl issue. There are a bunch of ways for similar to give you an OffsetArray when you don't want it