polygonize should return a MultiPolygon, not a Vector of Polygon

[rafaqz]

See: https://discourse.julialang.org/t/polygonize-a-raster/114189/7

[asinghvi17]

Shouldn't it actually return a feature collection, with one feature for each unique value? Or do you mean in the special case of an AbstractMatrix{Bool}, in which case I agree.

[rafaqz]

We don't actually do that case at the moment. But I'll add it, and yes that would need a FeatureCollection.

Currently is just Bool and f(x) -> Bool. I guess we can allow Integer arrays to be converted to FeatureCollection? But floating point would need some more complicated contour function.

(I guess we can make it a feature collection of pooled MultiPolygons, one for each value?)

[asinghvi17]

That sounds good to me.

Makie uses Contour.jl and Isoband.jl to generate isolines - perhaps we could create an extension on that and use it as an algorithm if needed, the necessary code can be copied wholesale from Makie.

[rafaqz]

This is actually a very different algorithm, its exact pixels like the raster. But we could have those too.

(practically ive found exact pixels better to work with, and most R packages do this too, or allow for 4/8/16 nodes rather than just 4, which I'm also considering doing)

[rafaqz]

I added handling for Integer, just returning a FeatureCollection of MultiPolygon. But maybe we can do this for other Number using either N isolines specified with a keyword nintervals (any better name ideas?) or with IntervalSets.jl intervals? Would that dependency be ok?

(and now I'm thinking this approach will be slow for large numbers of values, though its fast for small numbers... maybe we need to create all polygons at the same time...)

[rafaqz]

I have no guage of this being fast or not, its 10 million pixels and 400 categories...

julia> @time featurecollection = polygonize(rand(1:400, 10000, 1000));
 16.385245 seconds (29.87 M allocations: 7.798 GiB, 29.17% gc time)

The alternative is to do one pass and write an algorithm that considers all the neighboring categories and adds edges where needed. Probably 100x faster in this case, but slower for the base Bool case.

No scratch that the number of categories is not the main cost. Probably this can be faster with a Dict lookup

[asinghvi17]

Maybe test against Contours.jl? I can send a script later tonight once I get on the plane and have to stay awake.

I can see the appeal of exact pixel polygons though.

[asinghvi17]

Just thought of this but as you mentioned it's not really a comparison - the algorithms are too different!

[asinghvi17]

fixed by #141 I think