Closed evetion closed 1 year ago
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?
I should be more specific, most packages hardcode Vector{Vector{Float64}}.
I thought AbstractVector
was fine too. It really should be for performance
@evetion do you know witch packages use Vector
rather than AbstractVector
? lets just swap that.
I ran into this issue with conversion toLibGEOS.Polygon
from GeoJSON.Polygon
.
Ok, thinking about this some more, it's two issues:
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]]
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.
In the sense that an
GeoInterface.coordinates
will yield a JSON3 Array that no other package will parse as the coordinates they are.