BEGIN:VCALENDAR VERSION:2.0 PRODID:-//pretalx//talks.osgeo.org//foss4g-2026//talk//MSYSPT BEGIN:VTIMEZONE TZID:JST BEGIN:STANDARD DTSTART:20000101T000000 RRULE:FREQ=YEARLY;BYMONTH=1 TZNAME:JST TZOFFSETFROM:+0900 TZOFFSETTO:+0900 END:STANDARD END:VTIMEZONE BEGIN:VEVENT UID:pretalx-foss4g-2026-MSYSPT@talks.osgeo.org DTSTART;TZID=JST:20260902T173000 DTEND;TZID=JST:20260902T180000 DESCRIPTION:As smart buildings\, campuses\, airports\, and shopping malls g row increasingly complex\, the need for precise and reliable indoor locati on-based services has become critical. However\, unlike outdoor navigation —which benefits from decades of investment in mature infrastructure such as GPS\, OpenStreetMap\, and a rich ecosystem of standardized APIs—the indoor spatial data landscape remains fragmented. Addressing this gap requ ires not only robust data standards capable of representing indoor environ ments but also practical service interfaces that enable those standards to be easily used in real-world applications.\n\nOGC IndoorGML[1] is the int ernational standard that provides the formal foundation for indoor spatial information modeling. It represents indoor space using two complementary layers. The primal space layer encodes the physical geometry of indoor env ironments through cell spaces (e.g.\, rooms\, corridors\, and open areas) and cell boundaries (e.g.\, walls and virtual thresholds). In parallel\, t he dual space layer represents navigable connectivity as a graph\, with no des corresponding to navigable cells and edges representing their connecti vity. This dual representation enables both geometric description and topo logical reasoning for indoor navigation. The latest IndoorGML 2.0 specific ation further extends this model by introducing support for multi-layered space representations. This capability allows multiple thematic perspectiv es—such as topographic layout\, furniture configuration\, accessibility constraints\, or emergency routes—to coexist within a single building mo del. As a result\, IndoorGML 2.0 provides a flexible semantic framework ca pable of supporting diverse indoor service scenarios.\n\nDespite the richn ess of the IndoorGML data model\, most prior work has focused on the const ruction phase of the indoor spatial data lifecycle\, such as developing da ta generators\, editors\, and conversion tools. While these efforts have e stablished essential foundations for creating IndoorGML datasets\, compara tively less attention has been given to how such data can be efficiently s erved\, queried\, validated\, and consumed by downstream applications. Con sequently\, a persistent gap remains between the semantic expressiveness o f IndoorGML and its practical accessibility in production systems.\n\nA ke y challenge in bridging this gap lies in the encoding and delivery of Indo orGML data in web-based environments. IndoorGML was originally designed wi th an XML-based encoding schema that provides strict schema validation and strong standards compliance. However\, in practice\, XML-based workflows often introduce considerable operational overhead. XML requires constructi ng the full document tree before accessing individual elements\, involves relatively high parsing costs\, and typically depends on domain-specific l ibraries that complicate integration into modern software stacks. In contr ast\, JSON has become the (de-facto) standard data exchange format for web -based systems due to its lightweight structure and direct compatibility w ith modern programming environments. JSON-based data structures map natura lly to objects in most programming languages\, support incremental parsing \, and integrate seamlessly with web technologies such as JavaScript frame works\, mobile platforms\, and contemporary GIS clients.\n\nTo address thi s need\, IndoorJSON[2] has been proposed as a JSON-based encoding schema f or the IndoorGML 2.0 conceptual model and is currently being standardized by the OGC. IndoorJSON preserves the complete semantic structure of Indoor GML—including CellSpaces\, CellBoundaries\, Nodes\, Edges\, multi-layere d spatial models\, and dual-space connectivity graphs—while providing a lightweight and web-friendly representation suitable for modern developmen t environments.\n\nBuilding upon this encoding approach\, API – IndoorFe atures[3] is designed to operationalize IndoorGML-based data in web servic es. Rather than relying on customized or proprietary encodings\, the API d irectly adopts the upcoming standardized IndoorJSON schema\, ensuring inte roperability and long-term compatibility within the evolving OGC ecosystem . In this sense\, the implementation also serves as a practical proof of c oncept demonstrating that IndoorJSON-based indoor spatial data exchange ca n be deployed reliably in operational systems and can fully support real-w orld navigation and querying tasks.\n\nAPI – IndoorFeatures is implement ed as a RESTful service that exposes IndoorGML 2.0 data encoded as IndoorJ SON through HTTP endpoints. The API allows developers to access and utiliz e indoor spatial data without requiring detailed knowledge of the underlyi ng IndoorGML data structures. The implementation is built on extending pyg eoapi[4]\, a Python-based framework that conforms to OGC API standards\, a nd extends it with indoor-specific functionality while maintaining compati bility with the OGC API – Features[5]. In the system architecture\, Indo orGML geometries and topological relationships are stored in PostgreSQL/Po stGIS\, enabling efficient spatial indexing and complex SQL-based queries. Indoor routing operations are supported through pgRouting\, which operate s directly on the dual-space connectivity graph stored in the database. To maintain data consistency\, all write operations are validated against In doorGML 2.0 requirements\, ensuring that the stored data preserves the sem antic integrity of the standard. Additionally\, a bundled web application provides interactive visualization\, geometric querying\, and routing capa bilities directly within a browser environment.\n\nThis study presents the design requirements and implementation considerations encountered during the development of API – IndoorFeatures and evaluates its effectiveness through practical use cases using real building datasets. By extending the indoor spatial data lifecycle beyond data construction to include serving \, validation\, sharing\, and consumption\, this work provides a reusable\ , extensible open-source platform to support the development of next-gener ation indoor location-based services.\n\nReferences:\n[1] OGC IndoorGML 2. 0 Part1 – Conceptual Model\, https://docs.ogc.org/is/22-045r5/22-045r5.h tml \n[2] IndoorJSON Schema and Sample Data\, https://github.com/opengeosp atial/IndoorGML-SWG/tree/master/IndoorGML2/IndoorGML2_metanorma/Part%20II/ JSON \n[3] API – IndoorFeatures\, https://github.com/STEMLab/API_IndoorF eatures \n[4] pygeoapi\, https://pygeoapi.io/ \n[5] OGC API - Features - P art 1: Core corrigendum\, https://docs.ogc.org/is/17-069r4/17-069r4.html DTSTAMP:20260717T225806Z LOCATION:Cosmos1 SUMMARY:Making OGC IndoorGML 2.0 Web-Ready: API – IndoorFeatures with Ind oorJSON - Dong Gwon\, Seongmin Choi URL:https://talks.osgeo.org/foss4g-2026/talk/MSYSPT/ END:VEVENT END:VCALENDAR