Proper verification of design assumptions in the early investment stages requires the creation of precise three-dimensional context models. Parametric topography and building volumes provide an essential foundation for advanced spatial analytics, including shading studies, visibility analyses, as well as calculations related to building physics and urban microclimate. Spatial definition of the surroundings enables the verification of the designed object’s relationship with the existing urban fabric, and the generated area additionally serves as a geometric reference for artificial intelligence systems used in the post-production visualization stage. Currently, the primary resource enabling the construction of such mock-ups is open spatial data provided by geodetic offices (e.g., the Polish Geoportal). For analytical purposes, datasets in the CityGML format, containing building models, and ASC files, representing the digital terrain model, are commonly used. However, processing this data in a typical architect’s workflow encounters difficulties arising from the specifics of database formats and differing geometry recording standards.
A complete context model usually requires supplementation with road infrastructure, downloaded from open resources such as OpenStreetMap (OSM). Consolidating data from these two sources reveals the problem of coordinate system inconsistencies. Models originating from the Polish Geoportal are saved in the flat metric system PUWG 1992 (EPSG:2180), while road data from OSM is based on the WGS84 geographic coordinate system. An additional engineering challenge is the correct localization of objects in virtual space. Models imported directly from GIS databases possess absolute geographic and elevation coordinates. In CAD programs (e.g., Rhinoceros 3D), this results in the geometry being placed at a significant distance from the origin of the coordinate system (Point 0,0,0), which generally leads to the collapse of the transformation matrix, shadow display errors, and image jitter. Therefore, determining a base point and translating the entire system becomes necessary.
Initial attempts to integrate the aforementioned datasets relied on a multi-stage process. CityGML files were converted to DXF format using intermediary software (e.g., FZKViewer), road data was downloaded via dedicated plugins (e.g., Heron in the Grasshopper environment), and the digital terrain model was loaded separately. It was observed that this process is characterized by a negligible degree of automation, forces work in fragmented software environments, and generates errors when manually aligning inconsistent coordinate systems.
To streamline the workflow, the first integrated parser was developed in Python, operating directly within the algorithmic Grasshopper environment. This solution allowed the process to be consolidated into a single program, but it quickly revealed performance limitations. Standard Python libraries, by loading the entire structure of extensive XML/GML files into RAM, caused significant stability drops when analyzing large-scale urban models. Processing individual city blocks took an amount of time that precluded smooth project work.
In response to the identified performance issues, the tool’s logic was implemented from scratch in C#. Using a stream reading technique instead of loading the entire document into memory reduced the parsing time of datasets (sometimes occupying several GB of memory) from hours or minutes to dozens of seconds. Furthermore, the process of draping roads onto the digital terrain model was optimized. Instead of the computationally heavy projection of perfectly smooth NURBS curves onto polygonal terrain meshes, a raycasting algorithm was implemented. The script virtually “samples” the terrain from the vertices of the linear road axes, which increased computation speed. A mathematical Gauss-Krüger projection was also implemented within the component, enabling precise and fully automated conversion of the spherical WGS84 system to the flat PUWG 1992 system without relying on external geodetic libraries.
The application of such an optimized script demonstrates a significant advantage over popular alternative tools. Automating platforms, such as Cadmapper, generally provide simplified volumes lacking official standardization, feature lower topographic mesh accuracy, and omit tall vegetation. On the other hand, professional GIS software (e.g., QGIS) proves effective in two-dimensional analytics but does not constitute a standard design environment for architects. The developed C# algorithm allows for the generation of correct geometry (in LOD1 or LOD2 standard) based on verifiable state data, maintaining work within a native CAD ecosystem.
A particular value of the custom component is the ability to directly transfer the processed data to the Revit environment via Rhino.Inside. This process solves one of the primary problems of context modeling in BIM technology, which is the pollution of project files with difficult-to-edit and hardware-intensive polygonal meshes. The script enables the transfer of clean, topologically correct closed solid geometry (brep). Additionally, it allows context elements—such as tall vegetation—to be mapped directly to Revit families. The transition from the spatial analysis stage in Rhino to the design phase occurs using the same standardized dataset, further enriched with descriptive parameters (metadata) extracted from GML files. This guarantees the maintenance of full informational and structural integrity of the model at every stage of the project.
To present the methodology of the custom parser’s operation, a functionally simplified version of the tool (CityGML Extractor LITE) was developed. The script, available for download below, extracts building geometry from single GML files, illustrating the baseline logic of topology and coordinate system translation before implementing the full scope of spatial analyses.