IFC praxe II. - PHP parser

V první části minisérie IFC praxe jsme se zabývali východisky problematiky analýzy struktury a obsahu negrafických informací obsažených v BIM modelech. Dnes se zaměříme na jeden ze základních "strojů" využívaných pro tyto analýzy - IFC parser.

V ČEM JE OBECNÝ PROBLÉM BIM MODELŮ?

• ve složitosti struktury
• v nestálosti schematu
• ve velikosti objemu dat

Postup řešení

• využití faktu, že jde o řádkový textový soubor
• vytvoření databázového obrazu tohoto souboru 1:1
• vytvoření pomocných identifikátorů
• použití sady SQL nástrojů pro analýzu negrafických informací v modelu

První krok - import do databáze

• IFC-SPF soubor je nejprve nahrán do úložiště na serveru pomocí FTP funkce v PHP.
• Do importu se zahrne pouze obsah v sekci DATA, ostatní se ignoruje.
• Nahraný soubor je načítán po jednotlivých řádcích, resp. po jednotlivých instancích.
• Každá instance je podrobena prvotnímu rozkladu. Separuje se referenční číslo, název entity a sada atributů.
• Referenční číslo představuje primární index databázové tabulky. Sada atributů se zatím ponechává v původní formě.
• Takto vznikne databázová tabulka, která může mít i několik milionů řádků.
  Nicméně i standardní hosting podle získaných zkušeností tento úkol zvládne.

Druhý krok - analýza atributů

• Jednotlivé atributy představují seznam hodnot oddělený čárkami.
• Je několik typů hodnot:
  - odkaz na jinou instanci. Je uveden referenčním číslem a znakem "#" na začátku, např. "#16"
  - výčtové či logické hodnoty jsou uvedeny velkými písmeny s tečkou na začátku a na konci, například ".TRUE."
  - hodnoty řetězců jsou uvedeny v ASCII znakové sadě s uvozovkami na začátku i na konci. Pro znaky s kódem větším než 126 se používá speciální kódování. Pro typické osmibitové (např. západoevropské) nebo šestnáctibitové (Unicode) znakové sady jsou navrženy specifické kódovací postupy.
  - celá čísla a reálné hodnoty se používají shodně s typickými programovacími jazyky
  - agregáty (seznamy, pole..) jsou uvedeny v závorkách, oddělené čárkou

Proces analýzy atributů je tedy silně závislý na kontextu (znakové řetězce mohou obsahovat čárky i závorky ap.) a je nutno jej provádět prakticky znak po znaku. To může u rozsáhlých souborů trvat i několik hodin.

Třetí krok - přiřazení identifikátorů k hodnotám

Vzhledem k tomu, že atributy v IFC souboru jsou uvedeny v pevném pořadí stanoveném pro každou entitu, je možno při dostatečné znalosti příslušného EXPRESS schematu vytvořit dvojice identifikátor - hodnota. Třebaže tento proces zvětší objem dat v databázi, zvýší efektivitu další práce. Tyto dvojice je výhodné uložit do strukturované podoby - aktuálně byl použit zápis formou JSON (JavaScript Object Notation), mimo jiné i proto, že je přímo podporován novými verzemi MySQL a MariaDB.

Čtvrtý krok - zpracování relací

Zde se postupně interpretují jednotlivé relační entity tak, aby byl vytvořen kompletní hierarchický strom (tzv. strom budovy). V obrazu databáze to znamená, že každý produktový element obsahuje referenci na jeho nadřízený prvek.

Další pomocné kroky

Pro náš hlavní úkol - ověření a extrakci dat pro správu a provoz budovy (Facility Management) - je vhodné doplnit databázové záznamy o další datové prvky, které usnadní třídění a agregaci. Jsou to:

• uložení kódu a popisu elementu do samostatných polí, aby je nebylo nutno opakovaně získávat ze seznamu atributů
• určení klasifikační úrovně záznamu.
  Do první úrovně jsou zařazeny elementy prostorové struktury (projekt, staveniště, budova, podlaží, prostor).
  Do druhé úrovně elementy stavebních konstrukcí (zdi, sloupy, desky, okna, dveře ..). Do třetí úrovně prvky vybavení (rozvody elekrické i instalační, koncové prvky rozvodů, nábytek, technické vybavení).
  Do dalších samostatných úrovní jsou zařazeny entity představující klasifikace, relace a vlastnosti
• výpočet podřízených součástí (počet "dětí")
• vytvoření seznamu vlastností

Tolik tedy k problematice převodu IFC do SQL databáze. V příštím díle minisérie si povíme více o jak proces analýzy zautomatizovat, aby se maximálně snížila jeho časová náročnost a byl dle potřeby kdykoliv opakovatelný.