Related:

• Deprecate "groups" as a concept from the DataResultTree. #4441
• Update DataResultTree to start at origin and introduce "projected" subspace #4156
• Add support for $origin in EntityPathExpressions #5288

Proposal

Every Space View has a property: “origin”:

• Why “origin” vs “root”:
  • root is overloaded -- the notion of an arbitrary per-space-view root has the potential to be confusing.
  • This way we can reserve ”root” to refer to the root: “/” in all contexts without needing to qualify “Space View Root” vs “Global Root”
• Why is it a property of the SpaceView rather than the Query?
  • We want to use origin to talk about how the space-view interprets the data -- this is independent of the data-query itself and should work even if the data-query specifies data relative to “/”.
  • Even when we provide multiple queries, it’s very helpful for a SpaceView to have a single concept of origin.

When evaluating a query-expression, we allow for substitution of “$origin”

• Why “$origin” instead of “.”
  • It’s less special
  • $origin is clear and explicit in it’s meaning.
  • Avoids subtlety of “path” vs “/path” vs ‘./path”
  • When writing/evaluating queries, don’t need to think about concepts of “scope”. It’s just an optional prefix. Can always fully expand without changing interpretation.
  • $var substitution is universally understood. Opens pathway to other parameterized substitutions in the future.
  • Using “.” leads to introducing of “..” which gets messy (more on that below)

The default query for every spaceview becomes “$origin/**”

• This matches the behavior today, but happens at evaluation time rather than query-creation time which makes the behavior more reasonable when changing the origin.

When displaying the query results under a SpaceView the query results are divided into two sub-sets:

• The entities below $origin
• The entities not below $origin which we refer to as “Projected” entities
  • Often times the Projected set will be empty
• Why “Projected?”
  • The most common case for using above-origin entities is things like 3D -> 2D projectoin
  • It reinforces for users the meaning/importance of origin which is that it defines a “space” within your data hierarchy. Data which is not part of that space must be projected into it, even if that projection is trivial.
• Why don’t we use “../..” style paths?
  • The nesting-logic gets confusing and they become hard hard to follow when there are multiple included paths above the origin with different levels of nesting.
  • The mix particularly poorly when using “...” to indicate a truncated path

# Trivial
rr.view.Spatial2D(origin="world/camera")

# Implies
rr.view.Spatial2D(origin="world/camera", contents="$origin/**")

# Which is syntactic sugar for:
entities = rr.view.EntityPathExpression("$origin/**")
rr.view.Spatial2D(origin="world/camera", contents=entities)

# With extra data
rr.view.Spatial2D(origin="world/camera", contents="+$origin/** +/world/points")

# Or for python formatter clarity, allow lists:
rr.view.Spatial2D(
    origin="world/camera",
    contents=[
        "+$origin/**",
        "+/world/points",
    ],
)

# A less toy example
rr.view.Spatial2D(
    name="Left Gripper View"
    origin="/sim.32/world/robot.S23056387/left/arm/upper/lower/sensor_rig/camera/",
    contents=[
        "+$origin/**",
        "+/sim.32/world/robot.S23056387/**",
        "+/sim.32/world/global_map/**"
    ],
)