Introduce space-origin-relative paths for entity-path-expressions and query results

[jleibs]

Related:

• [x] https://github.com/rerun-io/rerun/issues/4441
• [x] https://github.com/rerun-io/rerun/issues/4156
• [x] https://github.com/rerun-io/rerun/issues/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)

![image](https://github.com/rerun-io/rerun/assets/3312232/65e4ef17-0d49-4f80-8ebf-f0840ff44c7b)

```python
# 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/**"
    ],
)

[abey79]

Related issue re: proper visibility handling in the hierarchy:

• https://github.com/rerun-io/rerun/issues/3194

As noted in the discussion today, this is temporarily going to be more complicated when Groups are removed, and call for either:

• a complex, tristate sort of visibility widget in the blueprint tree;
• or a basic one, and advanced visibility controls added to the context menu.

[abey79]

We discussed the "visibility" issue with @nikolausWest this morning and the outcome was:

• ok to regress in the short-term
• fixing #3194 would go a long way towards making that regression acceptable as is
• risk: a larger redesign may end up being necessary to address the larger problem of property inheritance and override...
• ...but we can't really act on it right now. Let's move on according to the present issue and get a feel for it before further design.