-
Notifications
You must be signed in to change notification settings - Fork 1
try GeometryBasics metadata approaches #3
Conversation
The current implemenation is starting to hold well for homogeneous types. While for heterogeneous data The this type inconsistency occurs while creating the vector of Feature structs -> Line - 34 |
I don't fully understand the issue for heterogeneous types. We are using |
With these types of custom types, you can't really expect StructArrays to know how to widen things correctly upon collection, or at least, I don't know a good way to do it in practice: how would StructArrays figure out that the first type parameter is linked to the first field? In principle, one could allow the widening mechanism to be customizable, but that is not implemented in StructArrays at the moment. I think it's much easier to create the So something like maketable(iter) = maketable(Tables.columntable(iter)::NamedTuple)
# assuming `geometry` is first in `propertynames(f::Feature)`
maketable(cols::NamedTuple) = maketable(first(cols), Base.tail(cols)) # you could also compute the types here with `Base.tuple_type_tail` and `Base.tuple_type_head`
function maketable(geometry, properties::NamedTuple{names, types}) where {names, types}
F = Feature{eltype(geometry), names, StructArrays.eltypes(types)}
return StructArray{F}(; geometry=geometry, properties...)
end Note: this requires overload both |
Not sure if it's correct, but I wonder if it was possible to write a |
Let's keep it as simple as possible, and only focus on constructing it from a list of vectors for now. |
The new approach works well! For weird reasons I was getting a |
Add tests for getter methods Add maketable and other tests
Add codecov/badges
This reverts commit 7b7cce3.
Update Readme
Closing as we've decided to keep the wrapped JSON3 Objects as a kind of lazy geometry type, and implement GeoInterface on them, such that we can easily convert to GeometryBasics or other more useful geometry types. |
It's nice to use this as a basis for exploring the GeometryBasics approach to metadata, right now for JuliaGeometry/GeometryBasics.jl#49.
Since GeoJSON is a well defined standard, we know exactly what we need. Currently in this PR the switch to GeometryBasics geometries has already been made. To explore the needs for a future metadata in GeometryBasics, I avoided using meta geometries for know, and simply used
Feature
as a composed geometry and named tuple.FeatureCollection
currently holds a vector ofFeature
s, but should be switched to StructArrays as suggested in JuliaGeometry/GeometryBasics.jl#49.Supersedes #2