search

hypertidy / silicate

A general form for complex data
https://hypertidy.github.io/silicate/
53 stars 4 forks source link

"c" method #137

Open mpadge opened 3 years ago

mpadge commented 3 years ago

@mdsumner dunno whether this has been discussed elsewhere (alas it's a bit hard to accurately search for "c" :smirk: ), but is there a c method to join multiple silicate objects? And if not, could it be implemented?

mdsumner commented 3 years ago

toyed with at some point

https://github.com/hypertidy/silicate/blob/454bfd3b68af6c23cc6571ca5636c9d4430ea3ab/R/SC0-model.R#L7

mpadge commented 3 years ago

aha, thanks! But not yet exported as S3 generic, right? Whatever ... feel free to close if you want.

mdsumner commented 3 years ago

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 🙂

mpadge commented 3 years ago

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?

mdsumner commented 3 years ago

True 👍