core silicate (write definitions out)

[mdsumner]

We've established the worker verbs

sc_coord, sc_path, sc_edge, sc_segment, sc_vertex, sc_node, sc_arc, sc_uid

the universal model

SC

and the exemplary models

PATH, ?

Working in pslg branch

• remove PRIMITIVE
• create SC, consider removing PATH
• fix sc_arc to return the entities, replace with contracted graph
• make sc_uid generic
• make sc_uid able to retain incoming labels, or create them if needed
• incorporate dodgr workers
• write about the core

• translators with the universal central form
• relation to interactive graphics
• examples with representing gg objects
• relevance to tracking and routing
• relevance to rgl, svg,

[mdsumner]

We have a core mode that is pure segments, SC. The dodgr engine will produce the three table model from any input.

vertex, edge, object

This is equivalent to the EDGE/PRIMITIVE prototypes currently that will be removed.

Other models are PATH, PRIMITIVE0D/1D/2D/[nD] and these don't extend SC but can exist alongside, or exist exclusively. Any operation that changes the vertex or segment sets should propagate throughout the other model tables if present. I'm pretty sure we can invalidate always by default, because recreating these tables is pretty easy. Costly conversions are generating triangulations, but other things are essentially very low cost.

• generating triangulations
• re-triangulating, globally or locally
• traversing edge graphs to generate SF paths
• grouping primitives to generate boundaries (including non-SF, Manifold objects)
• generally, update processes will invalidate other models and require their re/creation (optimization can come later)

[mdsumner]

SC now

• has object, object_link_edge, edge, vertex tables

The reduce/join trick doesn't work because edge is "wide". Can we sneakily longify it?

Things to consider:

• when it's all edges, the path groupings become superfluous if these are trivial to recompute from the maps (nice!)
• the vertex pool doesn't really need to be filtered, and this provides a neat selection mechanism
• plotting the bounds of the vertices and adding the selected edges makes a nice global/local scheme

[mdsumner]

we need quads to triangles as well as triangles to segments hypertidy/anglr#36

[mdsumner]

models

model	entities	compulsory
SC	object	no
.	edge	yes
.	vertex	yes
PATH	object	no
.	object_link_path	no
.	path	yes
.	path_link_vertex	yes
.	vertex	yes
TRI	object	no
.	object_link_tri	no
.	triangle	yes
.	vertex	yes
DEL	object	no
.	object_link_tri	no
.	triangle	yes
.	vertex	yes
ARC	object	no
.	object_link_arc	no
.	arc	yes
.	vertex	yes
QUAD	object	no
.	object_link_quad	no
.	quad_link_vertex	yes
.	vertex	yes, but could be a transform

Only PATH has a relation between path and object, or path and vertex. Operators that deal with models without non-compulsory entities can simply provide dummy ones. That way grouping is always optional, we can always simplify to a pure graph.

It's compelling to keep the path definitions but it ends up being unclear - either an non-normal table with keys on object and path, or the need for another link table between object and path. It's the same with the other models, only objects really need to go with primitives - and if we need paths then we can store that on the object_link_[primitive] table - or create an new model.

Ultimately if paths exist but are not recorded they may be inferred by tracing through segments, any non-internal (to an object) edge is a candidate. See here for rough workings that dodgr-tech will sort out for us:

http://rpubs.com/cyclemumner/291561
http://rpubs.com/cyclemumner/291560
http://rpubs.com/cyclemumner/291559

As it stands TRI extends sc with triangles, and silicate wil use decido to generate them. anglr will add DEL model, a specialization of TRI with better quality triangles. If we can get a non-problematic license triangulation library in R then silicate can use that and drop the anglr version.

[mdsumner]

Also incorporate (if useful) #46

[mdsumner]

Definitions:

• brackets enclose required columns
• double brackets mean nested list-cols, with structural indexes
• .vx[n] vertex of a primitive with n starting at 0 and going up (point, edge, triangle, ...)
• vertex_ is for the vertex pool (.vertex0, .vertex1 etc. now deprecated)
• native_ is orientation of an edge, is it oriented as it came in or was it reversed (for this instance)
• visible_ is a triangle status, it might be part of a hole
• SC0 can have a single nested .vx0, or both .vx0 and .vx1 (in theory could also have triangles)

The current definition

• SC0
  ** object [[topology_]]
  ** vertex [x_, y_, ...]
  ** meta [proj, ctime, ...]

• SC
  ** object [object_]
  ** object_link_edge [object_, edge_, native_]
  ** edge[.vx0, .vx1, edge_]
  ** vertex [x_, y_, ..., vertex_]
  ** meta [proj, ctime, ...]

• TRI / DEL (they are the same, just created differently)
  ** object [object_]
  ** triangle [.vx0, .vx1, .vx2, object_, visible_]
  ** vertex [x_, y_, ..., vertex_]
  ** meta [proj, ctime, ...]

Not final

PATH and ARC are implemented, but still under review.

• PATH
  ** object [object_]
  ** path[object_, path_, ncoords_, ...] ## gibble stuff
  ** path_link_vertex[path_, vertex_]
  ** vertex [x_, y_, ..., vertex_]
  ** meta [proj, ctime, ...]

• ARC
  ** object [object_]
  ** object_link_arc[arc_, object_]
  ** arc_link_vertex[arc_, vertex_] ## note, no arc table - because sequential model, not primitive
  ** vertex [x_, y_, ..., vertex_]
  ** meta [proj, ctime, ...]

Not implemented

PATH and ARC could both be compacted in PATH0 and ARC0 forms by nesting links.

• ARC0
  ** object[orientation_, [[arcs_]]] ## nested arc index, orientation around a feature
  ** arc[arc_, [[vertex_]]] ## nested vertex index
  ** vertex[x_, y_, ..., vertex_]
  ** meta [proj, ctime, ...]

• PATH0
  ** object[[path_]] ## nested gibble run-length map
  ** vertex[x_, y_, ..., vertex_]
  ** meta [proj, ctime, ...]

[mdsumner]

With the zero-versions of models we need at the very least round-tripping for each model type, so

SC -> SC0 and vice versa

SC0 is a root-type, so SC.default can actually convert to SC0 and then put itself together. That means types have to have identity functions e.g. SC0.SC0 <- function(x, ...) x

That also means we have a generic model.class method that uses the verbs.

• SC/SC0
  ** sc_object
  ** sc_edge
  ** sc_vertex

• TRI/TRI0

WIP

etc.

From this plan write tests for every which-way case. I've simplified plot.SC to convert to SC0, you don't get colours by default unless you pass them in (in base way) or they exist on object$color_. More advanced plotting belongs somewhere else.

[mdsumner]

A recurring problem with PATH is that subobject/object and subobject_/object_ have been mixed and patchy. Currently I think it should be

• gibble subobject, object always integer
• silicate subobject_, object_ always character

But, PATH0 implies that object$path_ currently uses object_/subobject_ and these are integers (that makes sense, but should the "0" imply we stick with integer as per gibble?)

In PATH()$path we end up with both sets of columns, so it should always be that subobject is integer, and object_, path_ are character. I think "subobject_" has to go.

[mdsumner]

Currently going with never having "subobject_", it's not an identifier but a context grouping - it's easiest to have it there even if degenerate, but it's not a uid. (Requires changes in gibble, but only for the silicate methods).

I also just noticed that TRI0 was never finished, so that's first.

[mdsumner]

Ah, it is there just needed exposure - the crux is

• we rely on decido in silicate (no RTriangle, that's in anglr)
• decido is PATH-based, so if it can't be a set of closed PATHs it can't be triangulate
• there's no SC->PATH
• there's PATH->TRI so even PATH0 gets turned into PATH before TRI or TRI0

It could be PATH0->TRI/TRI0 to avoid the extra PATH stuff

[mdsumner]

revisit from #117