Prawidłowa weryfikacja założeń projektowych na wczesnych etapach inwestycyjnych wymaga tworzenia precyzyjnych trójwymiarowych modeli kontekstowych. Parametryczna topografia i kubatury stanowią niezbędną bazę do przeprowadzania zaawansowanej analityki przestrzennej, w tym studiów zacieniania, analiz widoczności oraz obliczeń z zakresu fizyki budowli i mikroklimatu miejskiego. Przestrzenne zdefiniowanie otoczenia umożliwia weryfikację relacji projektowanego obiektu z istniejącą tkanką miejską, a wygenerowany obszar służy dodatkowo jako referencja geometryczna dla systemów sztucznej inteligencji wykorzystywanych na etapie postprodukcji wizualizacji. Podstawowym zasobem umożliwiającym budowę takich makiet są obecnie otwarte dane przestrzenne udostępniane przez urzędy geodezyjne (np. polski Geoportal). W celach analitycznych powszechnie wykorzystuje się zbiory w formacie CityGML, zawierające modele budynków, oraz pliki ASC, reprezentujące numeryczny model terenu. Przetwarzanie tych danych w typowym środowisku pracy architekta napotyka jednak na trudności wynikające ze specyfiki formatów bazodanowych oraz odmiennych standardów zapisu geometrii.
Kompletny model otoczenia wymaga zazwyczaj uzupełnienia o infrastrukturę drogową, pobieraną z otwartych zasobów takich jak OpenStreetMap (OSM). Konsolidacja danych z tych dwóch źródeł ujawnia problem niespójności układów odniesienia. Modele pochodzące z polskiego Geoportalu zapisane są w płaskim układzie metrowym PUWG 1992 (EPSG:2180), podczas gdy dane drogowe z OSM bazują na układzie współrzędnych geograficznych WGS84. Dodatkowym wyzwaniem inżynieryjnym jest poprawna lokalizacja obiektów w przestrzeni wirtualnej. Modele importowane bezpośrednio z baz GIS posiadają bezwzględne współrzędne geograficzne i wysokościowe. W programach typu CAD (np. Rhinoceros 3D) skutkuje to umiejscowieniem geometrii w znacznej odległości od początku układu współrzędnych (Punkt 0,0,0), co z reguły prowadzi do załamania macierzy transformacji, błędów wyświetlania cieni oraz drgania obrazu. Niezbędne staje się zatem wyznaczenie punktu bazowego i translacja całego układu.
Początkowe próby integracji wymienionych zbiorów opierały się na procesie wieloetapowym. Pliki CityGML konwertowano do formatu DXF za pomocą oprogramowania pośredniego (np. FZKViewer), dane drogowe pobierano przez dedykowane wtyczki (np. Heron w środowisku Grasshopper), a numeryczny model terenu wczytywano oddzielnie. Zauważono, że proces ten cechuje się znikomym stopniem automatyzacji, wymusza pracę w rozproszonych środowiskach oprogramowania oraz generuje błędy przy ręcznym wpasowywaniu niespójnych układów współrzędnych.
W celu usprawnienia przepływu pracy opracowano pierwszy zintegrowany parser w języku Python, operujący bezpośrednio w środowisku algorytmicznym Grasshopper. Rozwiązanie to pozwoliło na zgrupowanie procesu w jednym programie, jednak szybko ujawniło ograniczenia wydajnościowe. Standardowe biblioteki języka Python, ładując całą strukturę obszernych plików XML/GML do pamięci RAM, powodowały znaczne spadki stabilności przy analizie wielkoskalowych modeli miejskich. Przetwarzanie pojedynczych kwartałów zajmowało czas uniemożliwiający płynną pracę projektową.
W odpowiedzi na zidentyfikowane problemy wydajnościowe, logikę narzędzia zaimplementowano od podstaw w języku C#. Zastosowanie techniki czytania strumieniowego zamiast ładowania całego dokumentu do pamięci pozwoliło na redukcję czasu parsowania zbiorów (zajmujących niekiedy kilka GB pamięci) z kilku godzin minut do kilkudziesięciu sekund. Ponadto, zoptymalizowano proces rzutowania dróg na numeryczny model terenu. Zamiast obciążającego sprzętowo rzutowania idealnie gładkich krzywych NURBS na wielokątne siatki terenu (meshes), wdrożono algorytm śledzenia promieni (raycasting). Skrypt wirtualnie „próbkuje” teren z wierzchołków liniowych osi dróg, co zwiększyło prędkość obliczeń. W obrębie komponentu zaimplementowano również matematyczne odwzorowanie Gaussa-Krügera, co umożliwia precyzyjne i w pełni zautomatyzowane przeliczenie sferycznego układu WGS84 na płaski układ PUWG 1992 bez korzystania z zewnętrznych bibliotek geodezyjnych.
Zastosowanie tak zoptymalizowanego skryptu wykazuje znaczną przewagę nad popularnymi narzędziami alternatywnymi. Platformy automatyzujące, takie jak Cadmapper, dostarczają z reguły uproszczonych brył pozbawionych oficjalnej standaryzacji, cechują się niższą dokładnością siatki topograficznej i pomijają zieleń wysoką. Z kolei profesjonalne oprogramowanie GIS (np. QGIS) sprawdza się w analityce dwuwymiarowej, lecz nie stanowi standardowego środowiska projektowego dla architekta. Opracowany algorytm C# pozwala na generowanie poprawnej geometrii (w standardzie LOD1 lub LOD2) w oparciu o weryfikowalne dane państwowe, utrzymując pracę w natywnym ekosystemie CAD.
Szczególną wartością autorskiego komponentu jest możliwość bezpośredniego transferu przetworzonych danych do środowiska Revit za pośrednictwem Rhino.Inside. Proces ten rozwiązuje jeden z głównych problemów modelowania kontekstowego w technologii BIM, jakim jest zanieczyszczanie plików projektowych trudnymi w edycji i obciążającymi sprzętowo siatkami wielokątnymi (mesh). Skrypt umożliwia przekazywanie czystej, poprawnej topologicznie geometrii zamkniętych brył (brep). Ponadto pozwala na mapowanie elementów kontekstowych – takich jak zieleń wysoka – bezpośrednio na rodziny Revit. Przejście od etapu analiz przestrzennych w Rhino do fazy projektowej następuje przy użyciu tego samego, ustandaryzowanego zestawu danych, wzbogaconego dodatkowo o parametry opisowe (metadane) wyekstrahowane z plików GML. Gwarantuje to utrzymanie pełnej integralności informacyjnej oraz strukturalnej modelu na każdym etapie projektu.
W celu zaprezentowania metodyki działania autorskiego parsera opracowano uproszczoną funkcjonalnie wersję narzędzia (CityGML Extractor LITE). Skrypt, do pobrania poniżej , wyodrębnia geometrię budynków z pojedynczych plików gml, obrazując bazową logikę topologii i translacji układu odniesienia przed wdrożeniem pełnego zakresu analiz przestrzennych.