"c" method
Opened this issue · 5 comments
@mdsumner dunno whether this has been discussed elsewhere (alas it's a bit hard to accurately search for "c" 😏 ), but is there a c method to join multiple silicate objects? And if not, could it be implemented?
aha, thanks! But not yet exported as S3 generic, right? Whatever ... feel free to close if you want.
I was scared by it I guess, there's no real issue but you'd warn if different projections at least. I should resurrect but been stymied on this for various reasons a while now.
Can't remember a use case but I definitely had them, reading from a big source a feature at a time is a big one, and ultimately that should use {geometries} and {wk} to reboot. I'll happily export c() feel free to motivate me 🙂
All good for now - I need it to work like the c.osmdata method for sf, which i use quite a lot (it's the only way to construct OR-queries: typeA | typeB = c(extract(typeA),extract(typeB))). I'll like hard-code one in osmdata, because those are only sc-like structures anyway, with a heap of extra tables. Reason not to do that is because those are class "SC", "sc", "osmdata_sc", so the c method will dispatch on "SC", and conflict with any silicate-internal methods. Thoughts?
(And FYI, all i do is a simple check, index <- which(vapply(x, nrow, 1L) > 1) to identify tables, then just rbind them and remove duplicates. Your current SC0 version is much more hard-coded to silicate structures, but I don't think that's really necessary, right? Important things are only (1) checking consistency (for example, projections, as you state); and (2) de-duplication. Underlying forms of tables aren't relevant, right?
True 👍