So Query.jl should be quite performant? Do you happen to have a benchmark suite that compares several query frameworks, similar to your csv file reader benchmark? That should be a fairly useful tool.
I donât know the details, but isnât this required since vectors in R are restricted to a few element types? In Julia, this is not the case, so most tabular implementations just work with generic elements out of the box.
For sure, you could get basically the same functionality with a data frame with geo-data attached.
But there still might be good reasons for the own type, overloading plotting / mapping functions, or storing a geo-referencing system.
I just spent two weeks writing sf code and wanted to highlight that it basically represents the concept we are working towards.
Joining the discussion a bit late to ask if there was an agreement about where this interface should be implemented? Is it TableOperations.jl? LightQuery.jl?
For example, now I need a simple table view that includes rows and columns in the query, but it doesnât seem to exist. In TableOperations.jl, only column selectors exist.
Isnât that just the composition of the select and filter functions from TableOperations?