It is 2040, and you’re a hungry, busy PhD student in your office who has to attend a talk in thirty minutes. You place a DoorDash order from your favorite restaurant. An autonomous robot picks up your order from a restaurant in a mall. It then drives itself from the mall to your university, finds your office, and hand-delivers the food to you. You eat and then start walking towards Conference Room 4105. But wait, do you have to cross the bridge to reach 4105? You don’t wait to look for signboards and figure it out. You whip out your Augmented Reality (AR) glasses, which immediately connect to a CMU map and shows you the route. More broadly, this points toward a next generation of the Web in which digital information is anchored to physical locations. We refer to this as the Spatial Web.

Realizing such a future requires advances across multiple areas, including multi-modal perception, human–robot interaction, robot manipulation, and augmented reality displays. A largely ignored piece of the puzzle is the underlying mapping infrastructure, i.e., the system responsible for assigning semantic labels to physical spaces and representing relationships among them. In the scenario above, both the delivery robot and the AR glasses depend on maps spanning multiple environments, including the mall, public road networks, and the university’s indoor spaces.

At first glance, this vision may appear to be already addressed by existing mapping platforms such as Google and Apple Maps. However, these systems are fundamentally centralized: each is hosted, maintained, and controlled by a single organization. For example, Google Maps is operated entirely by Google. As illustrated in Figure 1, a centralized mapping architecture consists of a centrally managed map database coupled with location-based services that operate over this data to serve application requests. A routing service, for instance, executes shortest-path algorithms on the centralized map to support navigation applications.

A key limitation of today’s centralized mapping infrastructure is that applications can only access the information curated and exposed by the organizations that operate these platforms. Private entities such as universities and houses are often unwilling to upload their maps to centralized repositories maintained by third parties. Indoor map data is often sensitive, and ownership of such data is a primary concern for private organizations. Beyond these practical concerns, there is also a broader philosophical issue: we should be cautious about a future in which large portions of physically grounded digital applications (e.g., robotics, augmented reality) are reliant on a small number of dominant corporations.

The Internet and the Web solved this problem. While there were several initial attempts at centralizing content on the Web (e.g., ‘walled gardens’ such as AOL and MSN), the Web braved those attempts. Today we do not view the Web as belonging to a single commercial entity. Rather, it is a federation of various entities hosting their own content and services independently of each other. Contrast this with a world where everybody would have to upload their websites to AOL or Microsoft’s servers. It would mean a tremendous amount of power granted to a small number of corporations. We are on the precipice of large-scale deployments of physically-based devices such as robots and AR glasses that would benefit from spatial content. Therefore, I believe the time is ripe to think of an Internet-equivalent federated infrastructure for the physical world.

Our work, OpenFLAME (Open Federated Localization and Mapping Engine) ( HotOS ’25 , NINES ’26 ), proposes a systems infrastructure in which disparate organizations can maintain maps of their own spaces and serve location-based services to applications. In the above scenario, the university, for example, would maintain its own map and services on its own servers. A robot wishing to navigate within the university would request access to the university’s map server and use the services it provides. For instance, it might use a localization service to determine its position within the university campus and a navigation service to determine where to go. Importantly, access can be fine-grained: the robot does not need access to the entire map, but only to specific services or limited portions of the data required for its task.

In this post, I discuss the design principles behind OpenFLAME. OpenFLAME draws inspiration from the architecture of the Web, which has several parallels to our mapping problem. On the Web, independent organizations host their own websites and enforce their own access control policies. Analogously, OpenFLAME enables organizations to host maps for their own physical spaces, retaining full ownership of their data and complete control over access. The Web also provides a robust discovery mechanism through DNS: given a human-readable domain name, DNS resolves it to the servers that host the corresponding website. Maps require an analogous mechanism, i.e., given a physical location, the system must be able to discover and identify all maps hosted for that location.

The design of OpenFLAME section begins with a description of core abstractions defining maps , map servers , and map zones . The organization section describes the relationships between different map servers and zones. I then explain how maps and zones on OpenFLAME express spatial coverage followed by the discovery queries model section that briefly talks about the mechanism to discover maps hosted on OpenFLAME. I conclude with final thoughts on the broader role of federated spatial infrastructure.

Design of OpenFLAME

Figure 2 shows the simplified architecture of OpenFLAME. Maps of different regions are stored on separate map servers maintained by independent organizations. Map servers also provide location-based services on top of the maps that they store. An OpenFLAME client discovers potentially zero or more map servers covering the region of interest using a federated spatial database. It then contacts these discovered servers to obtain services such as routing and localization, combining results from multiple maps when needed.

Abstractions: Maps and Map Servers

Map server. A map server is a system that stores the map of a region and provides map services on it. For example, a university building’s map server would store all the offices and navigable hallways in the building and might provide an image-based localization service to support AR applications. A map server can impose fine-grained security and privacy policies on users and applications.

Map. A map is a representation encoding relationships and attributes of spatial entities in a geographic region. While traditionally a map refers to the visual representation of geographic features, in our context it is the data that underlies such visual representations. We do not restrict the format in which map data is stored in individual map servers.

Map services. Location-based services built on top of maps are called map services. The green boxes in Figure 2 show some examples of map services. The routing service, for example, finds an optimal path between a source and a destination in a map. Clients access map data only through map services.

Map zone. Map servers are grouped to form a map zone for organizational convenience and ease of delegation. For example, the map servers of the different departments of a university form the map zone for the university (see Figure 3).

Each map server is registered under a zone. Both map zones and servers define their own coverage—the spatial extent they are responsible for. The coverage of a map server must lie entirely within the coverage of its zone. However, the coverage of a zone may extend beyond the combined coverage of its servers, meaning that zones can include “empty” regions that are not served by any map server. A zone can delegate the responsibility for parts of its coverage down to sub-zones. A zone can be registered with one or more parent zones.

For example, consider a university setting up its map on OpenFLAME. The university first defines the coverage of its zone, which spans all buildings on its campus. This allows the university to manage its zone independently of other map zones. It registers its zone with a parent zone, e.g., the city zone. Initially, much of the university zone’s coverage may consist of empty regions not served by any map server. Over time, individual university departments can populate the zone by registering their own servers, each covering their respective areas. Within the zone, these map servers operate independently of one another and their coverages can overlap with each other. The university facilities department, for example, could set up its own sub-zone and maintain all of its maps (e.g., electricity and plumbing plans) within this sub-zone.

The fundamental unit of discovery for spatial applications is the map server. Map zones exist primarily for organizational and administrative convenience of delegation. Applications do not need to interact with zones directly. However, zones can serve as an optional filtering mechanism; i.e., applications may restrict discovery to specific zones if they wish.

Organization of Map Servers and Zones

Map zones form a nested inclusion hierarchy; a child zone must be completely contained within its parent zone. The coverage of map zones can overlap with each other. Map servers are the leaves of this hierarchy. They always have a parent zone, and their coverages may also overlap.

An obvious starting point for organizing the hierarchy of map zones would be to reuse existing geopolitical hierarchies such as countries, states, and cities. However, such traditional hierarchies are not suited for our purpose. First, they are fraught with disputes. National boundaries are contested, and even property lines are frequent sources of legal conflict. Anchoring a technical system to these boundaries risks inheriting political disagreements. Second, geopolitical hierarchies generally assume exclusive ownership, where a region belongs to exactly one parent. This prevents benign overlaps, such as a university and a commercial provider both maintaining maps of the same campus.

The key difference between our approach and traditional hierarchies is the explicit allowance of overlaps. Multiple zones may cover the same physical region, and each can delegate to its own set of servers. This flexibility enables incremental deployment, where new maps can be attached under existing zones without requiring reorganization. Figure 3 shows an example map zone hierarchy with map servers within zones.

While overlaps enable easier integration of new maps, they also introduce challenges for map server discovery. A discovery query must now search across multiple branches of the hierarchy, increasing the complexity of discovery. We elaborate on this and discuss a feasible implementation in the paper.

Why hierarchy? Well, instead of organizing as a hierarchy, every map server could register its coverage with a centralized service that allows overlaps. This service could leverage existing spatial databases (e.g., MongoDB, PostGIS) to store the coverage of each map server simplifying the discovery process. However, this undermines the goals of federation, since new map registrations and updates to coverage would be controlled by a single entity. A hierarchical system provides structure and supports federation through delegation. It also scales more naturally with growth since new map providers only have to interact and register with their immediate parents. For example, the CMU Computer Science department could register its map on OpenFLAME by talking to the CMU zone as opposed to a larger centralized body. Note that additional functions such as identity verification of registrants could also be distributed in a hierarchy.

Expressing Coverage

Polygons are the most intuitive representation to express the coverage of map servers and zones, but operations such as intersection checks require complex spatial indexes that are costly to build and query in distributed settings. Furthermore, polygon-based queries are not amenable to distributed caching as they rely on exact spatial boundaries. Small differences in query boundaries can cause cache misses, reducing cache reuse and increasing recomputation costs.

We can instead express coverage as a collection of primitive shapes. Existing spatial indexing systems like H3 and S2 represent regions using primitive shapes. H3 and S2 decompose the world into hierarchically organized hexagons and squares respectively. The advantage of using spatial indexing systems is that discovery operations can be performed directly on the indices of primitive shapes. Moreover, queries for the same region can be cached using these indices as keys. Precisely expressing an arbitrary region might require a large number of primitive shapes. However, in practice, map coverage boundaries are rarely exact. While it is practical to guarantee that the coverage lies within a boundary, it is often difficult to assert that coverage of a zone or server extends up to every point of that boundary. We can exploit fuzzy boundaries to represent regions approximately and bound the number of primitive shapes required to cover them.

Unlike squares, hexagons do not exactly subdivide into child hexagons. As a result, the inclusion of children in parents is only approximate in H3, making S2 more suitable for representing an inclusion hierarchy of map zones. Therefore, we use the S2 spatial indexing system to express coverage as a collection of S2 cells, together with an optional altitude above sea level. Supporting altitude is crucial for indoor maps to disambiguate spaces at different floors in a building. Figure 4 shows an example of S2 cells representing a map zone. Check out our tool, Geodomain Explorer , to play with automatic generation of S2 coverage. The documentation on how to use the tool can be found here .

Discovery Query Model

A map server discovery query takes as input a list of S2 cells and, optionally, an altitude and a list of accepted map zones. It returns the set of map server addresses whose coverage intersects with the input S2 cells. Discovery is limited to a specific altitude if provided. It is also restricted to map servers registered within the accepted map zones list, if provided.

\[ \text{discover(S2 Cells, [altitude], [accepted map zones])} \rightarrow [\text{map server}_1, \text{map server}_2, \cdots] \]

For convenience, an application can represent the search region as a 3D bounding volume, i.e., an arbitrary 2D geographic shape (e.g., a polygon or circle) together with an altitude range. The OpenFLAME client library invoked by the application converts the bounding volume to a collection of S2 cells and altitude.

An application that already knows map zones relevant to its context can restrict the discovery process to those zones. For example, a university navigation application can restrict discovery to the university zone. If no list is provided, the discovery query is answered by first recognizing the set of map zones that cover a region followed by identifying all the map servers within these zones that cover the queried region. A consequence of allowing overlaps of map zones is that discovery queries now have to explore all branches of the map zone hierarchy that have coverage over the queried bounding region. Figure 3 shows an example where a query within a university returns maps across zones such as the city waterworks zone, university’s own zone and Google Maps.

Limitations. The discovery query model we adopt is inherently limited. It does not accept custom search terms and therefore cannot support nuanced queries such as “find only maps of shopping complexes in a city”. Importantly, it does not support ranking criteria to order the discovery results. As a result, querying over a region with many overlapping areas may yield large, unordered result sets. We envision that, once deployed, discovery of maps will evolve much like the Web. While the maintenance and updating of maps must be federated, much like websites on the Web are maintained independently, the discovery of maps can be centralized, analogous to a Web search engine. Centralized search engines would act as curators that crawl regions for available maps, index metadata and the services provided by map servers, and support richer search capabilities. Additionally, mechanisms such as external whitelists, blacklists, and ranking systems (e.g., crowd-sourced voting, auctions) can be employed to further tune discovery results. The discovery mechanism implementation included in the OpenFLAME system would still be essential to allow such out-of-band mechanisms to discover maps in the first place. We leave the study of nuanced map searches, filtering, and ranking mechanisms to future work.

Security Model

Threat Model. Once federated mapping is deployed at scale, it will likely reveal a wide and diverse attack surface. Map servers, for example, are vulnerable to attacks such as denial of service (DoS), reflection, and amplification. We believe that existing methods for DoS protection or anomaly detection could mitigate such attacks. In this work, we choose to focus on a subset of threats unique to OpenFLAME that stem from identity spoofing. Identity spoofing in this context refers to an adversary masquerading as a legitimate map server or zone, tricking applications into trusting falsified associations between regions and services. This would lead to threats such as cache poisoning and man-in-the-middle attacks. Identity spoofing may also result in denial of service for spatial applications as they could be bombarded with fake discovery results. Since caching is heavily relied upon in our model, and cached records may not always originate from the authoritative source, ensuring the authenticity of the discovery results is crucial.

Chain-of-trust model for spaces. Several existing models provide inspiration for how such identity authentication can be accomplished. For example, the Web relies on Public Key Infrastructure (PKI) , where trust anchors are global Certificate Authorities (CAs) that issue digital certificates binding identities to public keys. In contrast, DNSSEC and BGPSEC use hierarchical chain-of-trust systems, where authority is delegated step by step (e.g., root to top-level domain to child domain), and each link in the chain validates the next.

We adopt a hierarchical chain-of-trust model for OpenFLAME in which each zone signs all map servers and child zones registered with it. Clients performing discovery have configured trust anchors and validate results by ensuring that the signature chain extends to those anchors. We argue that this model is suitable for spaces as proving ownership of a map of a physical space requires proximity, which is something local or parent zones are more likely to possess than distant CAs. Furthermore, it is easier for new participants to prove their relationship to a parent zone than to undergo validation from an external CA (e.g., it is easier for a student club wanting to host a map of the university to request for validation from the university admins than from a centralized CA). Our data model is inherently hierarchical, making it natural for a parent zone that references a child to also provide a signed attestation of that child’s validity.

Limitations. Hierarchical chain-of-trust is inherently easier to compromise than a tightly controlled centralized PKI, as careless or malicious child zones may issue faulty signatures compromising the rest of the chain below them. As described in the previous section, we expect future spatial applications to rely on external curators, filter lists, and ranking mechanisms to select maps in a region. The security mechanism here serves to establish a baseline for identity.

Communication with Map Servers. Once map servers are discovered, clients can authenticate with them using standard mechanisms like password-based login or OAuth . As map servers are discovered dynamically, it becomes increasingly important for the client to authenticate the server’s identity (e.g., through X.509 certificates or DNSSEC ). Subsequent communication between clients and servers to obtain map services can leverage whatever security protocols are most appropriate for the application context. For instance, an image-based localization service might incorporate privacy-preserving features to preserve confidentiality of both the server and the client device (e.g., privacy-preserving VSLAM ).

Final Thoughts

A federated spatial platform will be a key part of the infrastructure needed to deploy robots and AR devices at scale. We believe OpenFLAME provides a good foundation for such an infrastructure. Please visit our website to learn more about it.

Just as applications today are built on top of the Web, future spatial applications could be built on top of the Spatial Web. These applications would discover and combine services from independently operated map servers as devices move across physical spaces, allowing a robot or AR device to function across organizational boundaries without relying on a single mapping provider.

Realizing this vision will require open standards, analogous to the Web and Internet standards of today, that define common interfaces for discovering map servers, describing spatial coverage, and requesting map services. On top of these interfaces, off-the-shelf models could provide spatial intelligence that helps applications interpret environments and use the services exposed by different map providers. This separation would allow map owners to retain control of their data while application developers build new capabilities against a shared platform.

At the same time, the interfaces to physical spaces must be designed carefully. Maps may expose sensitive information about homes, workplaces, and the people who occupy them. Spatial services should therefore reveal only the information required for a task and support strong authentication, fine-grained access control, and privacy-preserving computation. These protections are essential if the Spatial Web is to support a rich ecosystem of applications without compromising the security or privacy of the spaces on which they depend.