Semantyczna warstwa tożsamości obiektów infrastruktury liniowej

Abstrakt

Artykuł przedstawia koncepcję CIO (Canonical Infrastructure Object) – semantycznej warstwy tożsamości obiektów infrastruktury liniowej, która automatycznie rozpoznaje i spina reprezentacje tego samego fizycznego bytu w systemach BIM, GIS i Facility Management. Problem integracji geometrycznej BIM–GIS jest w literaturze dobrze opisany; niniejsza praca koncentruje się na nierozwiązanym problemie integracji semantycznej: automatycznym rozpoznawaniu tożsamości obiektów (Entity Resolution) dla geometrii liniowej, formalnej definicji tożsamości przez czas (algebra CIO) oraz budowie ontologii infrastruktury jako rozszerzenia standardów INSPIRE i IFC 4.3. Dla każdego z tych obszarów sformułowano otwarte pytania badawcze.

1. Wprowadzenie

Zarządzanie infrastrukturą liniową – mostami, wiaduktami, tunelami, drogami – wymaga równoległego dostępu do danych z co najmniej trzech odrębnych środowisk cyfrowych. Systemy klasy BIM (Building Information Modelling) przechowują geometrię przestrzenną i parametry techniczne obiektów. Bazy GIS rejestrują położenie i atrybuty obiektów w globalnych układach odniesienia, tworząc sieci topologiczne. Systemy Facility Management (FM) gromadzą historię eksploatacji, przeglądów technicznych i remontów.

Fundamentalny problem polega na tym, że te trzy środowiska opisują te same obiekty fizyczne, lecz w sposób wzajemnie nieprzezroczysty: nie istnieje żaden mechanizm który porównuje reprezentację IfcBridge w modelu Revit z rekordem bridge_PL_00234 w bazie GIS zarządcy drogi i wpisem asset_A1204 w systemie SAP AM. Powiązanie między nimi, jeśli istnieje, ma charakter nieformalny i zależy od wiedzy konkretnych pracowników.

Niniejszy artykuł proponuje koncepcję CIO (Canonical Infrastructure Object) – semantycznej warstwy tożsamości która automatycznie rozpoznaje i spina te reprezentacje. Koncepcja adresuje problem który literatura ostatnich lat konsekwentnie identyfikuje jako nierozwiązany: integracja geometryczna BIM–GIS jest możliwa, natomiast integracja semantyczna – rozpoznawanie tożsamości obiektów ponad granicami systemów i ponad zmianami w czasie – pozostaje otwartym pytaniem badawczym.

2. Stan wiedzy

2.1. Integracja geometryczna BIM–GIS

Problem georeferencji modeli IFC i konwersji między formatami BIM a GIS jest stosunkowo dobrze zbadany. Projekt GeoBIM Benchmark [1] systematycznie ocenił narzędzia do georeferencji modeli IFC oraz konwersji między IFC a CityGML, wskazując na istotne straty danych i niespójności semantyczne przy konwersji między standardami. Standard IFC 4.3, opublikowany jako norma ISO w 2024 roku, wprowadził klasy obiektów dla infrastruktury liniowej: IfcBridge, IfcRoad, IfcRailway [3,8]. Na poziomie europejskim dyrektywa INSPIRE (2007/2/WE) zdefiniowała schemat wymiany danych przestrzennych dla sieci transportowych (Transport Networks) z klasami RoadLink, RoadNode i TransportLinkSequence (European Commission, 2024; D2.8.I.7 v3.2) [5].

Wdrożenia praktyczne – m.in. projekt Calle 30 w Madrycie (2023–2024, integracja BIM+GIS+FM dla 30-kilometrowej obwodnicy miejskiej z wiaduktami i tunelami) oraz platforma cyfrowych bliźniaków Rijkswaterstaat w Holandii – potwierdziły wykonalność integracji geometrycznej w skali projektu [2].

¹ Datacomp IT sp. z o.o., Kraków, a.tomana@datacomp.pl, Kraków, lipiec 2026

2.2. Luka semantyczna

Najnowsze publikacje konsekwentnie wskazują ten sam nierozwiązany problem. J. Cepa et al. [2] stwierdzają, że „konieczne jest dalsze wzmocnienie powiązania semantycznego – powiązanie geometryczne wydaje się rozwiązane, ale semantyczne jeszcze nie”. Badania włoskich ośrodków (Sapienza Roma / Politecnico di Torino, PMC 2026) potwierdzają, że „problemy interoperacyjności między GIS a BIM oraz zarządzania danymi instytucjonalnymi pozostają niewystarczająco zaadresowane w aktualnych badaniach”[4].

Problem jest precyzyjnie zdefiniowany: standard INSPIRE udostępnia atrybut ExternalObjectIdentifier (European Commission, 2024), który umożliwia przypisanie zewnętrznego identyfikatora – ale zakłada, że identyfikator ten już istnieje i jest znany. Nie istnieje natomiast mechanizm który generuje ten identyfikator automatycznie na podstawie geometrii i kontekstu, gdy żadnego wspólnego klucza nie ma – a taki jest stan zdecydowanej większości polskiej infrastruktury powstałej przed erą cyfrową.

3. Koncepcja CIO – warstwa kanoniczna

3.1. Definicja i uzasadnienie

CIO (Canonical Infrastructure Object) to referencyjny obiekt infrastrukturalny pełniący funkcję warstwy tożsamości położonej ponad systemami BIM, GIS i FM. CIO nie zastopuje żadnego z tych systemów. Pełni funkcję analogiczną do numeru PESEL w odniesieniu do osób fizycznych: istnieje niezależnie od systemów które opisują ten sam obiekt, nie zmienia się wraz ze zmianą danych w tych systemach i nie znika po remoncie, migracji danych ani zmianie oprogramowania.

Kluczowe rozróżnienie konceptualne: podejścia dotychczasowe – w tym INSPIRE i IFC 4.3 – rozwiązują problem opisu obiektów infrastrukturalnych. CIO rozwiązuje problem tożsamości tych obiektów: mechanizmu który stwierdza, że opis w BIM i opis w GIS dotyczą tego samego fizycznego bytu.

3.2. Architektura

Rysunek 1 przedstawia architekturę warstwy CIO w odniesieniu do systemów źródłowych.

Jeden rekord CIO zawiera cztery elementy:

Element CIO	Treść i funkcja
Identyfikator globalny	Trwały, niezależny od systemu źródłowego. Format roboczy: CIO-PL-00234-B (kod kraju ISO 3166, numer sekwencyjny, typ obiektu). Nie zmienia się po remoncie ani migracji danych.
Wskaźniki do systemów	BIM: IfcBridge_007 | GIS: bridge_PL_00234 | FM: asset_A1204. CIO nie zastępuje żadnego z tych rekordów – rejestruje tylko, ze opisują ten sam obiekt fizyczny.
Geometria kanoniczna	Uproszczona reprezentacja wystarczająca do rozpoznawania tożsamości: os liniowa obiektu z georeferencja w układzie ETRS89. Nie jest to pełny model BIM ani baza GIS.
Historia operacji	Algebra CIO zapisuje zdarzenia dotyczące obiektu w czasie: Renovation, Extension, Split, Merge. Po każdym zdarzeniu identyfikator CIO pozostaje ten sam; zmienia się historia. Fundament: ontologia PROV-O (W3C).

4. Algorytm rozpoznawania tożsamości obiektów

Centralnym wyzwaniem algorytmicznym projektu jest automatyczne rozpoznanie, ze obiekt w modelu IFC i rekord w bazie GIS opisują ten sam fizyczny byt – gdy nie maja wspólnego klucza, gdy geometrie wyrażone są w różnych układach współrzędnych i gdy jakość danych źródłowych jest zróżnicowana.

Proponowane podejście opiera się na trzech kryteriach dopasowania (ang. matching criterion), ocenianych łącznie przez agenta decyzyjnego:

• Kryterium 1 – geometria liniowa: miara pokrycia geometrycznego po przekształceniu do wspólnego układu; kandydaci z pokryciem powyżej progu kalibrowanego są traktowani jako potencjalne pary tożsamościowe.
• Kryterium 2 – kontekst topologiczny: weryfikacja czy obiekty lezą na tej samej drodze według Linear Referencing System (LRS) i czy sąsiedztwo w grafie sieci jest spójne. Kryterium to rozstrzyga przypadki gdy geometria jest niejednoznaczna.
• Kryterium 3 – atrybuty semantyczne: zgodność typu obiektu (Bridge, Viaduct, Tunnel) i klasy drogi (A, S, GP…) jako dodatkowe potwierdzenie.

Rysunek 2 przedstawia logikę algorytmu jako diagram przepływu.

4.1. Otwarte pytania badawcze

• Kalibracja progów: wartości progowe (pokrycie geometryczne, tolerancja długości) wymagają kalibracji empirycznej na zbiorach rzeczywistych danych. Optymalny próg zależy od klasy drogi, epoki budowy i źródła danych geometrycznych.
• Niejednoznaczność: jak rozstrzygać przypadki brzeżne (pokrycie 50–85%) bez interwencji człowieka? Czy możliwe jest uczenie maszynowe na przykładach manualnie rozstrzygnięte?
• Transformacja układów: konwersja geometrii liniowej z lokalnego układu kartezjańskiego BIM do ETRS89 z zachowaniem topologii i punktów charakterystycznych – nierozwiązany problem dla złożonych obiektów (mosty lukowe, estakady wielopoziomowe).
• Asymetria jakości: modele BIM starszych obiektów maja często niższą dokładność geometryczna niż dane LiDAR/MMS. Jak algorytm ma ważyć sygnały przy asymetrycznej jakości danych?

5. Algebra tożsamości CIO

Trwałość identyfikatora CIO wymaga formalnej definicji kiedy obiekt po zmianie fizycznej lub administracyjnej pozostaje tym samym obiektem (ten sam CIO), a kiedy powstaje nowy. Proponujemy podejście oparte na ontologii PROV-O – W3C Provenance Ontology [7], która jest sprawdzonym narzędziem do reprezentacji historii i pochodności danych w systemach prawnych i archiwalnych. PROV-O definiuje trzy klasy podstawowe (Entity, Activity, Agent) oraz relacje proweniencji (wasGeneratedBy, wasDerivedFrom, wasAttributedTo), które mapują się na zdarzenia w historii obiektu infrastrukturalnego.

5.1. Reguła T2 – tożsamość po remoncie

Najbardziej typowy scenariusz: istniejący obiekt przechodzi remont lub modernizacje. Pytanie: czy obiekt po remoncie przęsła to ten sam CIO czy nowy?

Intuicja: jeśli pokrycie geometryczne jest wystarczające i zdarzenie jest sklasyfikowane jako Renovation (nie NewConstruction), identyfikator CIO jest zachowany, a zdarzenie rejestrowane w historii operacji jako nowa wersja obiektu (prov:wasRevisionOf)[6].

5.2. Reguła T3 – podział obiektu

Scenariusz drugi: obiekt fizyczny lub administracyjny jest dzielony na dwa lub więcej części – np. odcinek drogi podzielony miedzy dwóch zarządców, lub most rozbudowany o nowe przęsło które staje się odrębnym obiektem ewidencyjnym.

Kluczowa właściwość: nowe identyfikatory CIO_B i CIO_C przechowują referencje derivedFrom do CIO_A, który otrzymuje status Archived. Pełna historia obiektu jest dostępna przez łańcuch referencji – analogicznie do mechanizmu wersjonowania w systemach kontroli wersji kodu.

5.3. Otwarte pytania badawcze

• Progi algebry: kalibracja progu pokrycia (60% w T2, 90% w T3) wymaga analizy empirycznej na zbiorze rzeczywistych zdarzeń remontowych z danymi historycznymi.
• Zdarzenia złożone: jak klasyfikować zdarzenia hybrydowe (remont połączony z rozbudowa)? Czy algebra powinna być kompletna (każde zdarzenie ma jednoznaczna klasę) czy otwarta?
• Konsekwencje prawne: w kontekście zarzadzania infrastruktura publiczna, kwestia tożsamości obiektu ma konsekwencje prawne w zakresie gwarancji i odpowiedzialności. Jak formalne reguły algebry CIO maja się do krajowych ram prawnych zarzadzania mieniem publicznym?

6. Ontologia infrastruktury i silnik wnioskowania

6.1. Projekt ontologii

Warstwa CIO wymaga formalnej reprezentacji wiedzy o tym czym jest obiekt infrastrukturalny, jak sie zmienia i jakie ma relacje z innymi obiektami. Proponujemy budowę ontologii w standardzie OWL 2 / RDF jako rozszerzenie i integracje trzech istniejących standardów:

• INSPIRE Transport Networks (tn:) – klasy i relacje dla sieci transportowych; gotowe mapowanie na dane GIS krajowych baz przestrzennych.
• IFC 4.3 (ifcOWL) – klasy obiektów budowlanych i infrastrukturalnych; fundament dla reprezentacji modeli BIM.
• PROV-O (W3C) – ontologia proweniencji danych; fundament dla historii operacji i algebry tożsamości CIO [6].

Synteza tych trzech standardów w jedna ontologie infrastruktury liniowej z warstwa CIO stanowi wkład który nie istnieje w literaturze i który może być zgłoszony do standaryzacji w ramach buildingSMART lub EuroSDR.

6.2. Reguły wnioskowania zarządczego

Ontologia z regułami SPARQL/SHACL tworzy fundament dla automatycznego wnioskowania zarządczego: systemu który sam generuje informacje których zarządca nie zapytał. Dwa przykłady:

Reguła Z1: wymagalność przeglądu technicznego

Reguła Z2: spójność danych miedzy systemami

6.3. Otwarte pytania badawcze

• Zupełność reguł: jak zdefiniować minimalnie kompletny zbiór reguł dla zarzadzania infrastrukturą drogową? Jakie jest kryterium kompletności i jak je weryfikować?
• Rozwiazywanie konfliktów: gdy reguły dają sprzeczne wyniki, jak system powinien postępować? Czy możliwe jest formalne zdefiniowanie hierarchii reguł?
• Walidacja SHACL: jak projektować schematy ograniczeń (ang. SHACL Shapes) żeby były restrykcyjne semantycznie, a jednocześnie tolerancyjne na braki danych typowe w starszej infrastrukturze (cześć atrybutów nigdy nie została zdigitalizowana)?

7. Schemat identyfikacji CIO

Projektowanie docelowego schematu identyfikatora CIO jest samo w sobie otwartym problemem badawczym. Wymagania sa czterowymiarowe:

• Interoperacyjność: zgodność z ExternalObjectIdentifier w INSPIRE i z GlobalId w IFC.
• Globalność: unikalność w skali europejskiej bez konieczności centralnego rejestru.
• Odporność: identyfikator nie może ulec kolizji po zmianie granic administracyjnych ani przy podziale obiektu.
• Czytelność: identyfikator powinien być interpretowalny przez człowieka, a nie tylko maszynowo.

Dwa alternatywne podejścia wymagają oceny. Format czytelny dla człowieka (CIO-PL-00234-B: kraj, numer sekwencyjny, typ obiektu) jest interpretowalny i diagnostyczny, ale wymaga centralnego rejestru numerów sekwencyjnych na poziomie krajowym. Format UUID v5 generowany deterministycznie z geometrii i kodu kraju jest globalnie unikalny i nie wymaga rejestru, ale jest nieczytelny dla człowieka. Wybór miedzy tymi podejściami wymaga analizy doświadczeń istniejących systemów, m.in. INSPIRE OID, GS1 i systemu ISBN.

8. Podsumowanie i wnioski

Artykuł przedstawia koncepcje CIO jako semantycznej warstwy tożsamości obiektów infrastruktury liniowej. Problem który koncepcja adresuje – automatyczne rozpoznawanie tożsamości obiektów miedzy systemami BIM, GIS i FM – jest w literaturze konsekwentnie identyfikowany jako nierozwiązany, równocześnie zaś rośnie jego znaczenie praktyczne wraz z upowszechnieniem cyfrowych bliźniaków infrastruktury i europejskimi wymaganiami INSPIRE.

Sformułowane w artykule otwarte pytania badawcze obejmują cztery obszary: algorytmikę rozpoznawania tożsamości dla geometrii liniowej, algebrę tożsamości CIO przez czas, ontologie infrastruktury jako syntezę INSPIRE i IFC oraz schemat identyfikacji. Każdy z tych obszarów stanowi samodzielny problem badawczy; łącznie tworzą spójny program badan który może stanowić podstawę wspólnego projektu naukowego.

Temat niniejszego artykułu pojawił się w trakcie prac związanych z integracją BIM i GIS na platformie BIMvision na poziomie geometrycznym. Opracowanie rozwiązania BIMvision_python_bridge pozwoliło na opracowanie rozwiązań pilotażowych i ich walidacji na rzeczywistych danych projektowych [9].

Literatura

1. Noardo, F. et al. (2020). GeoBIM Benchmark 2019: Intermediate Results. ISPRS International Journal of Geo-Information, 9(6), 378. https://www.researchgate.net/publication/335986817_GEOBIM_BENCHMARK_2019_INTERMEDIATE_RESULTS
2. Jerez Cepa, J.J., García Alberti, M., Martínez Pavón, R., Calvo Benítez, J.A. (2024). Integrating BIM and GIS for an Existing Infrastructure. Applied Sciences, 14(23), 10962. https://www.researchgate.net/publication/386157655
3. Borrmann, A. et al. (2024). Building Information Modeling, 2nd ed. Springer. [IFC 4.3 infrastructure extensions], https://link.springer.com/book/10.1007/978-3-658-33361-4
4. Scolamiero, V., Boccardo, P. (2026). A BIM-Based Digital Twin Framework for Urban Roads: Integrating MMS and Municipal Geospatial Data for AI-Ready Urban Infrastructure Management. Sensors, 26(3), 947. https://pmc.ncbi.nlm.nih.gov/articles/PMC12899344/
5. European Parliament (2007). INSPIRE Directive 2007/2/EC. Transport Networks Data Specification v3.2, D2.8.I.7.
6. W3C (2013). PROV-O: The PROV Ontology. W3C Recommendation. W3C Recommendation 30 April 2013
7. Lebo, T., Sahoo, S., McGuinness, D. et al. (2013). PROV-O: The PROV Ontology. W3C Recommendation. https://www.w3.org/TR/prov-o/
8. buildingSMART International (2024). Industry Foundation Classes IFC 4.3.2.0 – Infrastructure Domain Extension. ISO 16739-1:2024. https://standards.buildingsmart.org/IFC/RELEASE/IFC4_3/
9. A.Tomana, https://bim4u.eu/jak-dziala-wtyczka-bimvision-python-api-bridge-szybka-walidacja-modelu/