BT
B.S. Tsai
info
Please Note
<p>This page displays the records of the person named above and is not linked to a unique person identifier. This record may need to be merged to a profile.</p>
2 records found
1
Master thesis
(2024)
-
B.S. Tsai, G. Agugiaro, C.A. León Sánchez, B.M. Meijers, Claus Nagel, Zhihang Yao
Semantic 3D city models are essential for visualising, analysing, and managing the built environment. CityGML is an international standard for representing 3D spatial information with a Unified Modelling Language (UML)-based data model to address data heterogeneity and facilitate data exchange. Common formats for encoding CityGML data include Extensible Markup Language (XML), CityJSON, and relational databases, with PostgreSQL preferred for its spatial data management capabilities enhanced by PostGIS.
Although relational databases like 3D City Database (3DCityDB) support CityGML v.1.0 and 2.0, challenges remain due to complex schemas and the need for advanced Structured Query Language (SQL) knowledge to access nested features and attributes of the encoded CityGML data, especially through Geographical Information System (GIS) software like QGIS, which is widely used by Architecture, Engineering and Construction (AEC) professionals. To address these issues, the 3DCityDB-Tools plug-in for QGIS (plug-in) developed by the 3D Geoinformation group at TU Delft simplifies interactions with 3DCityDB-encoded data by providing a user-friendly QGIS interface, enabling the creation of GIS layers composed of unique feature geometries and associated with attributes. With the release of CityGML v.3.0 in 2021, 3DCityDB is being updated to version 5.0, requiring corresponding changes to the plug-in for compatibility.
This thesis investigates the changes in the CityGML spatial concepts and the differences in 3DCityDB encoding. The methods are derived based on the 3DCityDB v.5.0 structure, which consists of schema-wise scans for checking the existing feature geometries and attributes. The scan results are then stored in the metadata tables for users to select the desired feature geometries and attributes for generating GIS layers. In the implementation, feature geometries are determined by the inherited fixed spatial properties of space or boundary features. In contrast, the feature attributes are classified into four types: ”Inline-Single”, ”Inline-Multiple”, ”Nested-Single” and ”Nested-Multiple” according to the modified 3DCityDB encoding. Each type requires specific flattening (linearisation) strategies to be joined with the geometries. Finally, users can generate GIS layers by joining the queried feature geometries and attributes. Several query time performance tests are conducted to determine the method for storing query results and creating the layers.
The generated GIS layers demonstrate flexible access to the feature geometries and attributes with enhanced attribute management. The attribute flattening method facilitates the consumption of complex attributes, making them accessible for batch querying in QGIS. While direct editing of geometries and attributes in GIS layers is not yet supported, these advancements increase the usability of CityGML data. Coping with the XML complex feature schema is a persistent technical challenge in the GIS applications; the proposed approach provides promising alternatives that align with the ongoing development efforts in the QGIS community, offering a complementary pathway for handling complex geospatial data. ...
Although relational databases like 3D City Database (3DCityDB) support CityGML v.1.0 and 2.0, challenges remain due to complex schemas and the need for advanced Structured Query Language (SQL) knowledge to access nested features and attributes of the encoded CityGML data, especially through Geographical Information System (GIS) software like QGIS, which is widely used by Architecture, Engineering and Construction (AEC) professionals. To address these issues, the 3DCityDB-Tools plug-in for QGIS (plug-in) developed by the 3D Geoinformation group at TU Delft simplifies interactions with 3DCityDB-encoded data by providing a user-friendly QGIS interface, enabling the creation of GIS layers composed of unique feature geometries and associated with attributes. With the release of CityGML v.3.0 in 2021, 3DCityDB is being updated to version 5.0, requiring corresponding changes to the plug-in for compatibility.
This thesis investigates the changes in the CityGML spatial concepts and the differences in 3DCityDB encoding. The methods are derived based on the 3DCityDB v.5.0 structure, which consists of schema-wise scans for checking the existing feature geometries and attributes. The scan results are then stored in the metadata tables for users to select the desired feature geometries and attributes for generating GIS layers. In the implementation, feature geometries are determined by the inherited fixed spatial properties of space or boundary features. In contrast, the feature attributes are classified into four types: ”Inline-Single”, ”Inline-Multiple”, ”Nested-Single” and ”Nested-Multiple” according to the modified 3DCityDB encoding. Each type requires specific flattening (linearisation) strategies to be joined with the geometries. Finally, users can generate GIS layers by joining the queried feature geometries and attributes. Several query time performance tests are conducted to determine the method for storing query results and creating the layers.
The generated GIS layers demonstrate flexible access to the feature geometries and attributes with enhanced attribute management. The attribute flattening method facilitates the consumption of complex attributes, making them accessible for batch querying in QGIS. While direct editing of geometries and attributes in GIS layers is not yet supported, these advancements increase the usability of CityGML data. Coping with the XML complex feature schema is a persistent technical challenge in the GIS applications; the proposed approach provides promising alternatives that align with the ongoing development efforts in the QGIS community, offering a complementary pathway for handling complex geospatial data. ...
Semantic 3D city models are essential for visualising, analysing, and managing the built environment. CityGML is an international standard for representing 3D spatial information with a Unified Modelling Language (UML)-based data model to address data heterogeneity and facilitate data exchange. Common formats for encoding CityGML data include Extensible Markup Language (XML), CityJSON, and relational databases, with PostgreSQL preferred for its spatial data management capabilities enhanced by PostGIS.
Although relational databases like 3D City Database (3DCityDB) support CityGML v.1.0 and 2.0, challenges remain due to complex schemas and the need for advanced Structured Query Language (SQL) knowledge to access nested features and attributes of the encoded CityGML data, especially through Geographical Information System (GIS) software like QGIS, which is widely used by Architecture, Engineering and Construction (AEC) professionals. To address these issues, the 3DCityDB-Tools plug-in for QGIS (plug-in) developed by the 3D Geoinformation group at TU Delft simplifies interactions with 3DCityDB-encoded data by providing a user-friendly QGIS interface, enabling the creation of GIS layers composed of unique feature geometries and associated with attributes. With the release of CityGML v.3.0 in 2021, 3DCityDB is being updated to version 5.0, requiring corresponding changes to the plug-in for compatibility.
This thesis investigates the changes in the CityGML spatial concepts and the differences in 3DCityDB encoding. The methods are derived based on the 3DCityDB v.5.0 structure, which consists of schema-wise scans for checking the existing feature geometries and attributes. The scan results are then stored in the metadata tables for users to select the desired feature geometries and attributes for generating GIS layers. In the implementation, feature geometries are determined by the inherited fixed spatial properties of space or boundary features. In contrast, the feature attributes are classified into four types: ”Inline-Single”, ”Inline-Multiple”, ”Nested-Single” and ”Nested-Multiple” according to the modified 3DCityDB encoding. Each type requires specific flattening (linearisation) strategies to be joined with the geometries. Finally, users can generate GIS layers by joining the queried feature geometries and attributes. Several query time performance tests are conducted to determine the method for storing query results and creating the layers.
The generated GIS layers demonstrate flexible access to the feature geometries and attributes with enhanced attribute management. The attribute flattening method facilitates the consumption of complex attributes, making them accessible for batch querying in QGIS. While direct editing of geometries and attributes in GIS layers is not yet supported, these advancements increase the usability of CityGML data. Coping with the XML complex feature schema is a persistent technical challenge in the GIS applications; the proposed approach provides promising alternatives that align with the ongoing development efforts in the QGIS community, offering a complementary pathway for handling complex geospatial data.
Although relational databases like 3D City Database (3DCityDB) support CityGML v.1.0 and 2.0, challenges remain due to complex schemas and the need for advanced Structured Query Language (SQL) knowledge to access nested features and attributes of the encoded CityGML data, especially through Geographical Information System (GIS) software like QGIS, which is widely used by Architecture, Engineering and Construction (AEC) professionals. To address these issues, the 3DCityDB-Tools plug-in for QGIS (plug-in) developed by the 3D Geoinformation group at TU Delft simplifies interactions with 3DCityDB-encoded data by providing a user-friendly QGIS interface, enabling the creation of GIS layers composed of unique feature geometries and associated with attributes. With the release of CityGML v.3.0 in 2021, 3DCityDB is being updated to version 5.0, requiring corresponding changes to the plug-in for compatibility.
This thesis investigates the changes in the CityGML spatial concepts and the differences in 3DCityDB encoding. The methods are derived based on the 3DCityDB v.5.0 structure, which consists of schema-wise scans for checking the existing feature geometries and attributes. The scan results are then stored in the metadata tables for users to select the desired feature geometries and attributes for generating GIS layers. In the implementation, feature geometries are determined by the inherited fixed spatial properties of space or boundary features. In contrast, the feature attributes are classified into four types: ”Inline-Single”, ”Inline-Multiple”, ”Nested-Single” and ”Nested-Multiple” according to the modified 3DCityDB encoding. Each type requires specific flattening (linearisation) strategies to be joined with the geometries. Finally, users can generate GIS layers by joining the queried feature geometries and attributes. Several query time performance tests are conducted to determine the method for storing query results and creating the layers.
The generated GIS layers demonstrate flexible access to the feature geometries and attributes with enhanced attribute management. The attribute flattening method facilitates the consumption of complex attributes, making them accessible for batch querying in QGIS. While direct editing of geometries and attributes in GIS layers is not yet supported, these advancements increase the usability of CityGML data. Coping with the XML complex feature schema is a persistent technical challenge in the GIS applications; the proposed approach provides promising alternatives that align with the ongoing development efforts in the QGIS community, offering a complementary pathway for handling complex geospatial data.
Student report
(2023)
-
B.S. Tsai, L.C. Huizer, M. Giampaolo, S. Monté, S. GONG, G. Agugiaro, Gabriel Garcia
This report details the development process of an open-data-based tool, an extension of the original interface created by Royal HaskoningDHV. The objective was to bridge the gap between geographical data and Architectural, Engineering, and Construction (AEC) industry applications. The tool aimed to transform spatial data for architects, facilitating contextual analysis in Rhinoceros and Grasshopper, ultimately aiding architects and engineers in enhancing designs based on environmental impact.
The initial tool focused on Netherlands data, but the ultimate goal was to make it applicable to other countries/regions. The research involved evaluating data availability for different regions, acquiring and aligning relevant data for Grasshopper, and implementing these data workflows into wind and solar analyses.
The data evaluation stage revealed challenges due to varying data availability and accessibility across countries. For example, Germany's fragmented data required navigating different portals, while Hong Kong's centralized data via API was more accessible. The lack of standardization hindered automation, necessitating manual data retrieval strategies that could be challenging for non-geomatics experts.
Data alignment methods varied, introducing complexities. For instance, Italy required 3D extrusion from 2D shapefiles, leading to unavoidable errors. Spain used a different method, showcasing the difficulty of a universal solution due to data standardization and interoperability issues.
Two techniques were envisioned for the open-data tool: TIN-based and Voxel-based methods, each with distinct qualities and limitations. The TIN-method offered high-quality analyses but required rigorous data alignment, while the Voxel-based method allowed flexibility but risked issues with resolution.
Limitations of exploratory analysis included a focus on five countries/regions and inherent constraints of Rhinoceros, limiting tool accessibility and requiring alternative approaches. Additionally, language barriers and data platform permeability might have led to overlooked datasets.
In conclusion, the report acknowledges the need for future work. Optimization of code for readability and performance is suggested, and the inclusion of additional data types (vegetation, land use, transport) in data workflows is proposed. Input from AEC professionals through methods like questionnaires or testing is recommended for further improvement. This report emphasizes the evolving nature of the tool and the importance of ongoing refinement to meet the needs of diverse AEC professionals. ...
The initial tool focused on Netherlands data, but the ultimate goal was to make it applicable to other countries/regions. The research involved evaluating data availability for different regions, acquiring and aligning relevant data for Grasshopper, and implementing these data workflows into wind and solar analyses.
The data evaluation stage revealed challenges due to varying data availability and accessibility across countries. For example, Germany's fragmented data required navigating different portals, while Hong Kong's centralized data via API was more accessible. The lack of standardization hindered automation, necessitating manual data retrieval strategies that could be challenging for non-geomatics experts.
Data alignment methods varied, introducing complexities. For instance, Italy required 3D extrusion from 2D shapefiles, leading to unavoidable errors. Spain used a different method, showcasing the difficulty of a universal solution due to data standardization and interoperability issues.
Two techniques were envisioned for the open-data tool: TIN-based and Voxel-based methods, each with distinct qualities and limitations. The TIN-method offered high-quality analyses but required rigorous data alignment, while the Voxel-based method allowed flexibility but risked issues with resolution.
Limitations of exploratory analysis included a focus on five countries/regions and inherent constraints of Rhinoceros, limiting tool accessibility and requiring alternative approaches. Additionally, language barriers and data platform permeability might have led to overlooked datasets.
In conclusion, the report acknowledges the need for future work. Optimization of code for readability and performance is suggested, and the inclusion of additional data types (vegetation, land use, transport) in data workflows is proposed. Input from AEC professionals through methods like questionnaires or testing is recommended for further improvement. This report emphasizes the evolving nature of the tool and the importance of ongoing refinement to meet the needs of diverse AEC professionals. ...
This report details the development process of an open-data-based tool, an extension of the original interface created by Royal HaskoningDHV. The objective was to bridge the gap between geographical data and Architectural, Engineering, and Construction (AEC) industry applications. The tool aimed to transform spatial data for architects, facilitating contextual analysis in Rhinoceros and Grasshopper, ultimately aiding architects and engineers in enhancing designs based on environmental impact.
The initial tool focused on Netherlands data, but the ultimate goal was to make it applicable to other countries/regions. The research involved evaluating data availability for different regions, acquiring and aligning relevant data for Grasshopper, and implementing these data workflows into wind and solar analyses.
The data evaluation stage revealed challenges due to varying data availability and accessibility across countries. For example, Germany's fragmented data required navigating different portals, while Hong Kong's centralized data via API was more accessible. The lack of standardization hindered automation, necessitating manual data retrieval strategies that could be challenging for non-geomatics experts.
Data alignment methods varied, introducing complexities. For instance, Italy required 3D extrusion from 2D shapefiles, leading to unavoidable errors. Spain used a different method, showcasing the difficulty of a universal solution due to data standardization and interoperability issues.
Two techniques were envisioned for the open-data tool: TIN-based and Voxel-based methods, each with distinct qualities and limitations. The TIN-method offered high-quality analyses but required rigorous data alignment, while the Voxel-based method allowed flexibility but risked issues with resolution.
Limitations of exploratory analysis included a focus on five countries/regions and inherent constraints of Rhinoceros, limiting tool accessibility and requiring alternative approaches. Additionally, language barriers and data platform permeability might have led to overlooked datasets.
In conclusion, the report acknowledges the need for future work. Optimization of code for readability and performance is suggested, and the inclusion of additional data types (vegetation, land use, transport) in data workflows is proposed. Input from AEC professionals through methods like questionnaires or testing is recommended for further improvement. This report emphasizes the evolving nature of the tool and the importance of ongoing refinement to meet the needs of diverse AEC professionals.
The initial tool focused on Netherlands data, but the ultimate goal was to make it applicable to other countries/regions. The research involved evaluating data availability for different regions, acquiring and aligning relevant data for Grasshopper, and implementing these data workflows into wind and solar analyses.
The data evaluation stage revealed challenges due to varying data availability and accessibility across countries. For example, Germany's fragmented data required navigating different portals, while Hong Kong's centralized data via API was more accessible. The lack of standardization hindered automation, necessitating manual data retrieval strategies that could be challenging for non-geomatics experts.
Data alignment methods varied, introducing complexities. For instance, Italy required 3D extrusion from 2D shapefiles, leading to unavoidable errors. Spain used a different method, showcasing the difficulty of a universal solution due to data standardization and interoperability issues.
Two techniques were envisioned for the open-data tool: TIN-based and Voxel-based methods, each with distinct qualities and limitations. The TIN-method offered high-quality analyses but required rigorous data alignment, while the Voxel-based method allowed flexibility but risked issues with resolution.
Limitations of exploratory analysis included a focus on five countries/regions and inherent constraints of Rhinoceros, limiting tool accessibility and requiring alternative approaches. Additionally, language barriers and data platform permeability might have led to overlooked datasets.
In conclusion, the report acknowledges the need for future work. Optimization of code for readability and performance is suggested, and the inclusion of additional data types (vegetation, land use, transport) in data workflows is proposed. Input from AEC professionals through methods like questionnaires or testing is recommended for further improvement. This report emphasizes the evolving nature of the tool and the importance of ongoing refinement to meet the needs of diverse AEC professionals.