the silicate API

[mdsumner]

Something just clicked in my head after re-reading a tweet by @tim-salabim, and I want to write some stuff down. There's an API for generating silicate forms, and primarily they have been focussed on sf objects, though also sp, trip are supported and I have other packages that deal with igraph, spatstat, rgl and some others.

I see the API working for geojson to deliver silicate-forms, and since GeoJSON strings don't have class attributes then I'll append "_sc" to each verb, and I imagine them working directly on character strings supported currently by geojson_sf. The verbs are

• sc_coord_sc - a data frame of all coordinates from all geometries in the order they occur (XY, XYZ, XYZM whatever is there)
• sc_path_sc - a data frame of ncol_, ncoords_ describing the number of coordinates in each component path, also identified by object_ (feature) , path_, and (for multipoly) subobject_
• sc_object_sc a dataframe of the feature attributes, with object_ as the link to the paths

This forms the basis of the PATH model in silicate, and creating methods for each verb allows PATH to be completely generic, and then there are other verbs to help create the other models (sc_vertex, sc_node, sc_edge, etc.). @mpadge then made me realize that we needed a truly universal primitive form (I was focussed on triangles), which is a purely edge-graph expression of any data object. That is now the SC model in silicate.

If we can write these verbs to work for GeoJSON sources then I'd have the basis for GeoJSON->silicate directly.

Perhaps you could lightly class in-memory strings, so that sc_vertex.gjson could work with the generic sc_vertex and it would handle your character, connection and geojson types. Alternatively, we develop a geojson_sc function that creates a PATH (or a SC) in whole, so then silicate can convert it to triangulations, or between path and edge forms - this is the approach @mpadge is taking in osmdata::osmdata_sc.

(It's also better to do a whole-model for something like geojson, because otherwise you actually parse/unpack for each verb, but please put that aside for now - this is a conceptual exploration and the verbs are easiest at first).

I've recently been restructuring silicate around the SC core, and now I have structural forms of each model type in development. These are SC0, PATH0 and so on, they are simpler, lighter, and used nested tibbles of indexes in the vertex table - so there's only two tables (object, vertex) - they are much simpler to create, but still I think they are a bit obtuse and need a lot more explaining -that's why I'm asking for help to go with the verbs approach above. sc_coord and sc_object are really simple, sc_path needs a bit more explaining - it's the same as the gibble::gibble function but with slightly different names.

Apologies is this is confusing, no problem if you can't see a way to approach this right now, I'll be back with questions no doubt!

I like where you're going, but I don't quite fully see how to get there yet. I'll be re-focussing on non-mapdeck stuff in the new year so I'll hopefully get to spend some time on understanding silicate, and how to integrate it into geojsonsf.