Philipp Rudiger

@jbednar I've added a proposal 3 to capture your suggestion of a graph-like representation.

While I totally understand your concern about the scalability of proposals 1 and 2 I've just done some testing and what I've found is that the bottleneck is the rendering...

Also @jlstevens just pointed out that if we only have to check for matches on the feature vertices (i.e. start and end nodes) the matching won't be expensive at all.

My suggestion would be to go with proposal 2 for the time being and if that proves to be problematic either due to scalability or for other reasons tackle proposal...

>Seems like once someone sets up a simulation using such a polygon, there can be some very long time series of data per node, with millions or billions of time...

>But doesn't such linking need an id for each node? That's accurate but that can be assigned at any point during or after the drawing. >It seems like any proposal...

>In certain cases it's fine to duplicate that information, but in the general case it's not, and I want to ensure that the overall solution doesn't require any unrealistic steps...

What I really want to know at this point is whether you're on board with making the current implementation work using proposal 1 or 2, which would require only the...

In that case I suppose I really don't understand the point you're making. To me it seems like **by far** the most complex starting point as well, since a single...

>A single list of nodes with associated arbitrarily many columns of data, and a separate data structure tracking connections between those nodes, is not a complex starting point Earlier you...