Federated Spatial Naming System

• Federated Spatial Naming Systems are decentralized architectures that resolve location-based services via independent map servers and domains.
• They employ diverse resolution methods—from geo-domain DNS records to spatio-temporal naming—to dynamically map names to localized services.
• These systems enhance scalability, privacy, and precision for applications like indoor navigation, AR, and sensor data retrieval while addressing governance challenges.

Searching arXiv for recent and foundational papers on federated spatial naming systems and related architectures.
Search query: federated spatial naming system OpenFLAME Internames spatial name system arXiv
A federated spatial naming system is a decentralized naming and discovery architecture in which spatial regions, spatio-temporal bindings, or location-scoped services are resolved by multiple independent authorities rather than by a single global map or database operator. In the literature, this idea appears in several closely related forms: OpenFLAME organizes the world into independent map servers and exposes “a seamless global view” for localization and mapping; Internames treats names as the primary abstraction and resolves them dynamically as a function of time, location, context, and service; the Spatial Name System makes physical presence and local spatial resolution central to naming; and ICN- or NDN-based federations expose spatial objects, tiles, or sensor products through routable names [2411.04271] [1401.0114] [2210.05036] [1903.05908] [2203.14426] [2507.11437]. Taken together, these works define a research area in which naming, discovery, routing, localization, and access control are all conditioned by geography, uncertainty, heterogeneity of coordinate frames, and administrative autonomy.

1. Definition, motivation, and conceptual scope

A federated spatial naming system replaces the assumption of a single authoritative spatial database with a federation of independently operated services. In OpenFLAME, these are “map servers”—localization services deployed by different parties that operate in their own coordinate frames and serve specific polygonal regions such as a building, a floor, or a department’s lab [2411.04271]. In the broader federated mapping formulation, a map server is analogous to a DNS zone: it is authoritative for some geographic region, but spatial authority differs from DNS authority because boundaries are often fuzzy and multiple servers may legitimately overlap the same physical area [2507.11437].

The need for federation is motivated by scale, privacy, and heterogeneity. Centralized map infrastructures are described as being “primarily controlled by a few large corporations and mostly cover outdoor public spaces,” while emerging spatial applications require indoor detail, private overlays, localization services, and access control that are not naturally exposed by a single global provider [2411.04271] [2507.11437]. One paper states that centralized infrastructures cannot practically survey and maintain “more than 100 billion square feet globally” of indoor space, and that building owners must control access to fine-grained data [2507.11437]. This suggests that federation is not only an implementation choice but also a governance model for private spatial data.

The concept also extends beyond cartography. Internames generalizes naming to “contents, users, devices, logical as well as physical points involved in the communication, and services,” with no static binding between a name and its current location [1401.0114]. The Spatial Name System pushes this further by treating a device’s physical presence in a region as the operative identifier for local interaction, so that naming is tied to a spatio-temporal object rather than a globally stable symbolic string [2210.05036]. ICN-based work on federated spatial databases and weather radars shows the same pattern in a data-centric form: spatial objects, query predicates, and sensor products are named directly, routed by name, and retrieved from multiple autonomous sites [1903.05908] [2203.14426].

A common misconception is that a federated spatial naming system is simply a distributed version of a conventional map API. The cited work argues for a stronger architectural shift: discovery becomes location-based, spatial authority becomes plural and overlapping, and client software becomes responsible for selecting, filtering, or stitching results across providers rather than assuming a single global truth [2411.04271] [2507.11437].

2. Architectural families

One architectural family is represented by OpenFLAME’s federated localization stack. Its architecture is described as a four-step pipeline: a device computes a coarse location from GPS, WiFi, or Bluetooth; converts that uncertainty region into geo-domains; performs DNS lookups to discover candidate map servers; and then sends localization cues such as camera images or sensor data to all discovered servers [2411.04271]. Each server returns a pose estimate in its own local coordinate frame plus a confidence value. The client computes an error score, filters viable servers, selects an active server, and continues with that server until quality degrades.

A second family is represented by Internames, which frames federation as a name-to-name communication architecture. Its basic building blocks are a name-based API, identifier–locator separation, and a Name Resolution Service that maps names to service descriptors as a function of time, location, context, and service [1401.0114]. The NRS can return one or multiple service descriptors, enabling policy-driven selection among multiple network-realms and name-realms. Name-routers then bridge heterogeneous realms such as IP, ICN, cellular, IoT, ad hoc, DTN, or data center domains.

A third family is locality-first. In the Spatial Name System, a realm is a physically bounded administrative cell such as a room, floor, building, campus, or city, and one or more local SNS servers are authoritative for a set of spatial tiles or regions [2210.05036]. Queries are resolved locally when possible; if a query spans realm boundaries, the local realm returns either a referral to peer realms or a proxied merged response. This architecture is designed to avoid WAN-resolution paths and to bind updates and access decisions to local presence and policy.

A fourth family is data-centric federation over ICN/NDN. In the spatial-database federation architecture, each database site has a federation front end, a query processor, a global index service, DBMS adapters, and an ICN forwarder. The control plane disseminates active tiles and routing prefixes; the data plane performs a two-phase retrieval in which a named query returns matching object names, and those named objects are then fetched individually as signed, cacheable content [1903.05908]. In weather-sensing federation, NOAA-like consumers pull radar products by name from multiple sites, while routers forward Interests by longest-prefix match, cache returned Data, and adapt to intermittent connectivity through re-expression, hop-by-hop forwarding, and multipath strategies [2203.14426].

Across these families, the same structural pattern recurs: federation is achieved by making administrative boundaries explicit, discovery contextual, and composition client- or resolver-driven rather than centrally orchestrated.

3. Naming, discovery, and resolution mechanisms

OpenFLAME’s naming system is geo-domain based. The client converts a coarse location, given as latitude, longitude, and error radius, into DNS-compatible names that index spatial regions [2411.04271]. The underlying space partition uses the S2 spherical geometry library, which divides the Earth into six top-level Faces and then recursively subdivides each face into four children per level down to level 30, where cells are about 1 cm². An S2 index is converted into a geo-domain by ordering child identifiers left-to-right and placing the Face at the root, yielding names such as 1.3.5.loc with parents 3.5.loc and 5.loc [2411.04271].

Discovery in OpenFLAME is performed with DNS TXT lookups rather than modified DNS semantics. The system introduces two logical record types encoded as TXT: MNS, a multi-valued delegation record analogous to NS, and MCNAME, a multi-valued alias record analogous to CNAME [2411.04271]. This design is motivated by two DNS constraints stated explicitly in the paper: “RFC 1034 disallows a single domain name to have multiple CNAME records,” and multiple NS records for a domain are not intended to represent parallel, independent delegations to different organizations. Clients therefore query geo-domains via TXT, parse MNS and MCNAME values, and recursively follow delegations to obtain candidate map-server endpoints. Parent queries are emphasized as essential because providers often register coarser cells than the client’s uncertainty region [2411.04271].

Internames offers a different resolution model. It keeps names stable and non-locational while delegating variability to the NRS, which maps names to service descriptors containing protocol, forwarding component name, and next-hop type and address [1401.0114]. Resolution is explicitly a function of time, location, context, and service, and policy-driven selection can be written as
$$
\ell^{*} = \operatorname*{argmin}_{\ell \in f(n,t,\mathbf{loc},c,s)} \; \text{cost}(\ell; \text{constraints, policies}).
$$
This formalism captures mobility, geofencing, realm choice, load, and trust without making the name itself unstable [1401.0114].

The Spatial Name System defines spatial names directly as spatio-temporal objects. A spatial name is represented as
$$
N = \langle R, t, a, o, f, q \rangle,
$$
where $R$ is a region, $t$ a time of interest, $a$ an accuracy parameter, $o$ an optional orientation, $f$ an optional radio fingerprint, and $q$ a quantization level [2210.05036]. Practical indexing uses hierarchical tilings such as geohash, H3, or Hilbert mapping. A region is encoded as a minimal set of one-dimensional Hilbert intervals, and within a realm the server resolves these intervals using an augmented interval tree with query time
$$
O(q(\log n + m)),
$$
where $q$ is the number of intervals, $n$ the number of stored intervals, and $m$ the number of overlaps [2210.05036].

NDN-based federations use names not only for discovery but also for exact data selection. In weather sensing, the paper’s central naming scheme is /data/radar1/_round=15/_seq=7, optionally extended with timestamps such as /addison/tx/radar1/_round=15/_seq=7/YYYYMMDD/HHMMSS [2203.14426]. The round/sequence structure makes a radar’s periodic production explicit and allows deterministic selection of synchronized files. In the spatial-database federation, object names follow the form /dbs#i/o/did/{objectId-version}, while named queries use /dbs#j/q/did/{query-statement/nonce} [1903.05908]. This separation between immutable object names and one-time query names enables safe caching of content while keeping query results uncached.

These mechanisms show that “spatial naming” is not a single syntax. It may be region-to-service mapping via geo-domains, stable identifiers mapped contextually by an NRS, explicit spatio-temporal names, or hierarchical content names whose prefixes encode federation, site, product, tile, time, version, and chunk.

4. Coordinate frames, map abstraction, and cross-domain composition

A central problem in federated spatial systems is that independently operated maps need not share a single global coordinate frame. OpenFLAME explicitly rejects forcing every provider into centimeter-accurate global alignment, arguing that such alignment “needs expensive survey equipment such as RTK GNSS and total stations” [2411.04271]. Instead, it exposes a public map abstraction based on waypoints: stable physical landmarks such as doors or intersections that are tagged in each local map. “Map servers never expose their map data”; only waypoints are exposed to clients, both for application anchoring and for stitching adjacent maps through shared waypoint identifiers [2411.04271].

For AR applications, OpenFLAME resolves coordinate-frame heterogeneity by transforming server-supplied waypoints into the device’s session-local application frame. If $P_A$ is the device pose in application frame $A$, $P_R$ the device pose in map frame $R$, and $W_R$ a waypoint in frame $R$, then
$$
W_A = P_A P_R^{-1} W_R.
$$
The paper also states the equivalent $SE(3)$ form,
$$
W_A = T_A T_R^{-1} W_R,
$$
with homogeneous coordinates [2411.04271]. The important architectural consequence is that cross-map consistency is handled at the application layer rather than by a global ICP merge of raw geometry.

The broader federated-maps literature generalizes this composition model to geocoding, reverse geocoding, search, routing, localization, and tile rendering. The client first discovers nearby or corridor-relevant servers, then issues per-service requests to each, and finally selects, ranks, or stitches the returned results [2507.11437]. For routing, each server computes routes within its own zone; inter-domain handoff occurs at overlaps or boundary waypoints, and end-to-end path construction is performed client-side [2507.11437]. For localization, the client can send modality-specific cues—images, fiducial tags, RF beacons—to overlapping servers and then choose the most plausible pose using confidence or IMU/SLAM consistency checks [2507.11437].

Internames offers an analogous composition mechanism at the network layer. It supports send-to-name, push, publish/subscribe, and return-path routing via names rather than relying on a fixed host-to-host path [1401.0114]. A service descriptor can select HTTP in one realm, CCN/UDP in another, or SIP in a third, allowing the same name to span IP and non-IP realms. A plausible implication is that spatial naming and network heterogeneity are coupled problems: a federated spatial system often requires both map-level stitching and protocol-level translation.

ICN-based federations make composition explicit in content retrieval workflows. In spatial databases, a global index identifies which database sites should be queried, each site returns object names, and the client or federation front end then fetches the signed GeoJSON objects themselves [1903.05908]. In weather sensing, a consumer maps a region of interest to named tiles or products, retrieves manifests or “current” pointers, pipelines chunk requests, and then mosaics the returned radar data while keeping round/sequence synchronization intact [2203.14426].

5. Security, privacy, and governance

Security and privacy are first-class concerns because federated spatial systems often manage indoor scans, private inventories, user locations, and administrative boundaries. OpenFLAME’s privacy model is explicit: “Map servers never expose their map data.” Providers retain sensitive indoor scans, clients send localization cues and receive poses, and only public waypoints are disclosed [2411.04271]. Providers may “implement access control to their service as necessary to meet the policy objectives of their relevant organizations,” so discovery does not imply authorization [2411.04271]. Discovery itself is protected in transit through DoH per RFC 8484, while the web-based implementation uses HTTPS for map-server exchanges [2411.04271].

A related governance issue is ownership. OpenFLAME “does not enforce exclusive digital ownership of a space,” meaning that multiple providers may register the same geo-domain and compete on localization quality rather than on exclusive namespace control [2411.04271]. Delegation through MNS records allows umbrella organizations, such as universities, to subdivide authority to departments without centralizing the underlying maps. This is structurally different from DNS, where one name belongs to exactly one zone [2507.11437].

Internames approaches the problem through authenticated resolution. Names can be tied to principals via certificates, service descriptors are signed by authoritative NRS servers, and the NRS can enforce access control based on spatial and contextual policy before returning descriptors [1401.0114]. Name-routers at realm boundaries also act as proxy/firewalls, limiting fake content injection and other cross-realm abuse. The system therefore centralizes trust at the resolution layer while still supporting multiple realms and dynamic rebinding.

The Spatial Name System emphasizes locality, physical presence, and short-lived credentials. Realm root keys issue short-lived credentials, device updates are sent over mTLS, and presence can be bound to short-range proofs such as one-time tokens carried by ultrasound or near-field beacons [2210.05036]. The detailed federation design further includes replay protection, motion-consistency validation, k-anonymity options, count-only responses, and location obfuscation through Gaussian perturbation when privacy-sensitive queries require intentionally coarser matching [2210.05036]. These mechanisms are designed to reduce exposure to remote attacks that scale across administrative domains.

ICN-based systems rely on data-centric security. In both radar federation and spatial-database federation, Data packets are signed objects, and consumers verify producer authenticity independently of the path [2203.14426] [1903.05908]. This allows in-network caching without surrendering integrity. In the spatial-database design, qData is not cached because result sets can change, whereas versioned oData is cacheable and immutable under a given object name [1903.05908].

An objective tension remains between federation and trust bootstrapping. Some works provide concrete cryptographic mechanisms, while the broader federated-maps paper explicitly notes that PKI details, auditability, and governance are “not specified” [2507.11437]. This suggests that operational trust frameworks remain a major unresolved component of production-grade federated spatial naming.

6. Performance, applications, and open problems

The strongest quantitative evidence currently comes from OpenFLAME, ICN-based federated spatial databases, and NDN weather sensing. In OpenFLAME, a typical discovery cycle queries “about 40 geo-domains” in parallel; the median number of geo-domains per query is approximately 36; the median number of uncached geo-domains is approximately 4; and the cache hit ratio becomes “close to 1” after the first request [2411.04271]. Client-side DNS bandwidth peaked at approximately 100 Kbps. Standard DNS server capacity remained at approximately 4 ms response latency up to 20,000 queries/sec, and the image-based implementation waited “over 1 second for the localization result from the map servers” [2411.04271].

The OpenFLAME case study is a web-based AR indoor navigation application deployed in a university building and across campus. Indoor regions were scanned via LiDAR or video plus SfM; waypoints were tagged for doors, intersections, and stairs; and discovery ran every two seconds [2411.04271]. Reported localization quality had median translational RPE of approximately 2.1 cm and rotational RPE of approximately $0.78^\circ$, compared with AprilTag baselines of 1.8 cm and $0.55^\circ$ [2411.04271]. DNS overhead was described as negligible, while VIO and WebXR maintained anchoring during the server-latency interval.

In federated spatial databases over ICN, experiments with 3 million European OpenStreetMap POIs reported a maximum stable query rate of approximately 125 queries/s for 100 km² queries and approximately 45 queries/s for 1,000 km² queries [1903.05908]. A three-level grid with adaptive tessellation and a default budget of 20,000 active tiles per database site supported global-index routing. The paper further reports that adaptive tessellation with $k \approx 10{,}000$ achieved near-optimal performance relative to an unconstrained tessellation of approximately 60,000 tiles, while reducing index-announcement size by approximately 80% [1903.05908].

In NDN-based weather sensing, the principal metric is synchronized retrieval quality rather than localization latency. Under TCP/IP push plus time windows, mosaics included only 40–50% of the ideal files per radar and the total files included varied between 12 and 24 versus the ideal 15; the NDN pull design with round/sequence naming “always delivered the ideal number (15)” [2203.14426]. The paper also reports that NDN completion times increase only slightly with RTT and loss, owing to cache-assisted recovery and the absence of aggressive TCP-style window back-off [2203.14426].

These systems support several application classes. OpenFLAME targets indoor AR navigation and other location-based applications spanning public and private spaces [2411.04271]. The broader federated-maps proposal discusses grocery-store product search, multi-domain routing from outdoor navigation to indoor shelf-level directions, campus navigation, fine-grained localization, and tile rendering from multiple providers [2507.11437]. Internames addresses mobility, disconnected operation, geofenced services, and push-based communication across IP and non-IP realms [1401.0114]. The Spatial Name System focuses on AR/IoT interaction in which nearby devices are resolved locally and securely by physical presence [2210.05036].

Several open problems recur across the literature. OpenFLAME states that “we do not automate the process of maintaining consistency” across maps and exposes tooling rather than automatic cross-map reconciliation [2411.04271]. It also notes the need for better record standardization, improved governance for multi-tenant geo-domains, broader localization-modality interoperability, and internet-scale evaluation under WAN conditions [2411.04271]. The federated-maps paper identifies heterogeneity of labels, coordinate frames, and 2D versus 3D fidelity as obstacles to seamless composition, and leaves collision resolution, deduplication, route optimization, and trust bootstrapping largely unspecified [2507.11437]. Internames identifies scalable, high-performance NRS design as the principal challenge for future implementation [1401.0114]. The Spatial Name System highlights trade-offs among precision, uniqueness, scalability, and privacy, especially in dense deployments where smaller tiles reduce collisions but increase fragmentation and reidentification risk [2210.05036].

The overall research trajectory suggests that federated spatial naming is converging on a common set of principles: region- or context-based discovery, independently administered authorities, explicit support for overlapping coverage, client- or resolver-side selection among multiple candidates, and security models that preserve data sovereignty while allowing interoperation. What remains unsettled is not the need for federation, but the standardization of naming semantics, trust relations, and cross-provider composition at internet scale.