Handle external maps

Context & Problem Statement

The next-generation Open-RMF core intentionally leaves map representation abstract to preserve framework pluggability. However, to build out a robust reference implementation, we must establish a concrete baseline format.
This issue addresses how the next-gen core should ingest, represent, alter, and expose spatial data to multi-agent path finding (MAPF) planners and fleet adapters.

Core Architectural Pillars

The Source of Truth: Semantic Lanelets via rmf_site

Instead of inventing a new map format, the reference implementation should natively rely on rmf_site (.site.ron) as its primary structural data model. It provides precise geometric primitives (points, lanes, polygons) along with critical semantic anchors (lifts, doors, speed zones).

The MAPF Gap: Bridge to Grid-World Topologies

Most state-of-the-art MAPF research (e.g., CBS, PBS) operates natively on uniform 2D grid worlds with discretized timesteps. Since Open-RMF natively uses rich, non-lattice lane networks via rmf_site, we face an optimization trade-off:

• Path A (Direct Continuous Planning): Adapt continuous-time, graph-based variants of MAPF (like SIPP/CCBS extensions) directly onto the parsed topological lanes.
• Path B (Deterministic Discretization): Implement a compilation layer that projects the topological rmf_site lanes onto a high-resolution grid world. The planner solves on the grid, and the resulting paths are mapped back to continuous fleet trajectories.

Ideally, our planner trait should be able to consume a generic Map object and depending on the user's choice of algorithm we should be able to re-cast

Dynamic Feedback Loop: Observation-Driven Replanning

Maps are rarely static. The reference architecture must support real-time map mutations driven by fleet observations (e.g., a robot's LiDAR detecting an unmapped obstacle or a localized costmap blockage). When an obstacle is reported, the architecture must support:

• Map Mutation: Dynamically introducing a temporary block or cost penalty to the specific region/grid cells.
• Planner Invalidation: A trigger mechanism that instantly signals the MAPF planner that the map topology has changed.

Proposed Technical Scope & Questions for the Community

• Map Compiler Architecture: Should the reference implementation ingest .site.ron directly into the core scheduler, or should map conversion (to grids or sparse routing graphs) live behind a modular plugin interface?

• Observation Ingestion API: How should fleet adapters broadcast obstacle observations? Do we introduce a standardized ObstacleObservation message that carries a geometry payload (bounding box/point cloud) and an estimated time-to-clear?

• Replanning Granularity: When a map update occurs, how do we avoid a costly global replan for all 100+ robots? Can we leverage incremental MAPF techniques or sub-graph replanning?

No implementation files or tests are named. Start by reviewing the rmf_site data model and the planner trait, then compare direct continuous planning with deterministic grid compilation and the proposed obstacle-observation flow. Done means the community has agreed on the map representation, conversion boundary, mutation and invalidation API, and replanning granularity.