JSON3 Array doesn't work with GeoInterface

[evetion]

In the sense that an GeoInterface.coordinates will yield a JSON3 Array that no other package will parse as the coordinates they are.

julia> GeoInterface.coordinates(poly1)
1-element Vector{JSON3.Array}:
 JSON3.Array[[0.1, 0.0], [1.1, 0.2], [0, 1], [0.3, 0.0]]

[visr]

Why is it that no other package will accept it? The docs say

Return (an iterator of) point coordinates.

For say a LineString we return a JSON3.Array of JSON3.Array, [[-89, 43], [-88, 44], [-88, 45]]. That seems to be ok since it contains coordinates, of which geomtrait returns PointTrait().

For say a MultiPolygon there are more nested arrays, like [[[ [-117.913883,33.96657], [-117.907767,33.967747], [-117.912919,33.96445], [-117.913883,33.96657] ]]]. I thought that GeoInterface.coordinates was supposed to be like GeoJSON coordinates, returning a list of polygon coordinates. But are you saying that it should return a fully flattened vector of points?

[evetion]

I should be more specific, most packages hardcode Vector{Vector{Float64}}.

[rafaqz]

I thought AbstractVector was fine too. It really should be for performance

[rafaqz]

@evetion do you know witch packages use Vector rather than AbstractVector ? lets just swap that.

[ianfiske]

I ran into this issue with conversion toLibGEOS.Polygon from GeoJSON.Polygon.

[evetion]

Ok, thinking about this some more, it's two issues:

• Some packages don't accept AbstractVectors
• JSON3 doesn't show the nested array, while most packages require the nested type.

julia> v
1-element Vector{JSON3.Array}:
 JSON3.Array[[100.0, 0.0], [101.0, 0.0], [101.0, 1.0], [100.0, 1.0], [100.0, 0.0]]

julia> copy.(v)
1-element Vector{Vector{Vector{Float64}}}:
 [[100.0, 0.0], [101.0, 0.0], [101.0, 1.0], [100.0, 1.0], [100.0, 0.0]]

[rafaqz]

So we really have to materialize at least the geometries from JSON3.jl to real Arrays. Although keeping the FeautureCollection itself lazy may be best. See https://github.com/quinnj/JSON3.jl/issues/250

That would solve this issue as well, although it would still be good if ArchGDAL accepted AbstractArray, for e.g. StaticArrays points to work.