Future work for the graph resource
Here is an umbrella issue collecting ideas for expanding/improving the smtk::graph::Resource
.
Runtime API and Python bindings
- Create runtime, non-templated accessor objects for nodes and arcs
- Use the runtime accessors to provide python bindings
- Create a runtime, non-templated generic arc API
- Use the API above to accept python-defined arc types.
Operations
- We have JSON bindings, but no read/write/create operations. Make some templated on a traits object?
- Add a "lint" operation (or a free function?) to validate arcs, check that consistency rules hold.
- Add some operations that perform graph analyses, such as
- Node degree statistics
- Graph cuts / partitioning that breaks fewest arcs.
- Node centrality computation
Presentation
- Create a node class-hierarchy subphrase generator.
- Create an arc-traversal subphrase generator.
- Prototype a 2-D node+arc layout? (a la the ParaView node editor)
- Prototype a 1-D node layout with arcs routed to the side.
- For high-level overviews, is there a subset of visual "super nodes" that should be rendered instead of showing all nodes+arcs?
Selection
- Investigate designs we might use for selecting nodes (i.e., what should the footprint of a selection be so that non-visual nodes can be selected by picking visual nodes? Which of these are exclusive with other selections – in the same way volumes and faces are exclusive in the model resource?).
Query grammar
- Investigate how to extend the query grammar to allow nodes to be selected based on their connectivity to other nodes along arcs of a given type.
- Investigate efficient use of a boost multi-index container for querying nodes based on things besides name, type-name, and id. (For example: properties on nodes, property values, arcs.) The issue is how to expose methods that ensure the index is properly updated without lots of developer pain.
Graph theory
- Investigate methods to expose matrix ←→ graph duality for mathematical analysis of graphs.
- Investigate techniques for storing edge weights.
In order to be general:
- A single edge may have multiple weights in different contexts.
- Maybe provide an API to get an integer for any pair of connected nodes? Then as many fields as you want could be stored as a map. Might also provide an API to "squeeze" assigned IDs into a contiguous range so fields could be represented as vectors? This seems like a good use of SMTK's query+cache mechanism, with the cache being invalidated (or at least marked dirty) after operations with write locks.