-
Notifications
You must be signed in to change notification settings - Fork 12
City2BIM Tool Overview
The City2BIM function offers the possibility to import buildings from CityGml files. In Germany (and other countries) 3D-models are governmental held in CityGml format (OGC standard - read here). The plugin offers the possibility to import buildings from these files to Revit.
The outer boundary surfaces of a building are imported in LOD1 or LOD2 (depending on availability) either as closed "watertight" solids (...as Solids) or as surface models (...as Surfaces).
- LOD1 data only contain a floor plan of the building extruded into the height (mostly building height at the ridge).
- LOD2 data are characterized by the consideration of the roof shape and are thus important e.g. for solar potential analyses.
Before data can be imported, it is recommended to adjust the settings:
The parameters for the import are stored in the settings:
- Data source: from server or local file.
- Settings for server query
- Settings for file import
- Translation of encodings in the CityGML
Using this option, CityGML data can be retrieved directly via a server request from the project partner virtualcitysystems. Technically, this is realized via a WFS (Web Feature Service) request. Information about this WFS you can get here (GetCapabilities XML document).
The WFS query requires the following parameters:
- URL of the WFS (already stored, editable via Edit URL in case of later changes)
- Center of the desired area (as default coordinate is set by georeferencing, can be changed via custom)
- Extent of the desired area in meters
If desired, the CityGML file returned internally by the server can also be saved locally in CityGML format. To do this, simply check the "save response" box and set a save destination via the "set folder" button.
An example of a server response (Center: 51.659987, 6.964985 / Extent: 300 m):
- Server queries only work on the territory of the Federal Republic of Germany!
- The data are returned according to the setting in the German standard system: ETRS89_UTM32 (EPSG:25832) or ETRS89_UTM33 (EPSG:25833).
- The quality of the data depends on the respective federal state (see next paragraph).
- The maximum return of buildings is limited to 2000 buildings. Please note this, when entering the parameter for expansion!
The data kept on the VCS server is provided depending on the legislation of each state. The data differ as follows (as of 01/2020):
- free city models in LOD2/LOD1, return contains mostly LOD2 data, ex: Berlin, Hamburg, Thuringia, NRW
- free city models, restriction to LOD1, e.g. Saxony
- no free city model data, e.g. Bavaria, Brandenburg. Free data from OpenStreetMap are used here. In this process, the floor plan stored in OSM is extruded upwards by 3 m per floor.
The type of data can be identified by the bldg: Building_ID stored as Revit parameter:
- Are colored roof areas included? --> official LOD2 dataset
- Does the Building_ID contain OSM? -> free (mostly inaccurate) OpenStreetMap data.
- Do both statements not match? -> official LOD1 data
An overview of 3D city model data provided by the server is possible by using the ""Germany" Viewers (Link)" from virtualcitysystems. By navigating the map application in the 3D view, buildings can be selected and their information displayed.
- City boundary Berlin - Potsdam (Brandenburg)
- Selection red: official LOD2 data from Berlin with roof shape and official ID
- Selection blue: LOD1 data with OSM source from Brandenburg (height roughly estimated, location accuracy uncertain)
If more detailed data in LOD2 is required, the respective state office (german: "Landesamt") must be contacted in most cases. They provide city model data on a file basis for a fee.
If the user has CityGml data locally, e.g. from an order placed with a responsible state office, this data can also be imported directly from the hard disk. To do this, the path to the file must be specified in the File text field.
In most cases, the (legal) data are available in the coordinate sequence YXZ. Should this not be the case, the order can also be changed to XYZ.
Attention: The file import does not filter the data with respect to the center of the project or its extension. It is therefore recommended not to import CityGML data that is too large (e.g. entire cities). In this case the import would take a long time or even fail.
Official geodata for 3D city models in Germany often contain numbers as attribute values, which represent an encoding of readable properties. Example attributes are the building function or the roof shape. The plugin offers the possibility to translate these encodings. For this, the corresponding checkbox should be set and the respective code list (AdV or SIG3D) should be selected. The official German data are mostly based on the coding of the AdV.
If all necessary settings have been set, the import of the data can take place. This requires a selection of the geometry type:
| LOD2 Buildings | as surface models (Surfaces) | as volume body (Solid) |--------|--------|
|||
Regardless of the selection, the following operations are always performed:
- Checking the input geometry
- Elimination of double points
- Elimination of line segments that do not form a surface ("dead end")
- no consideration of polygons which have less than 3 points and which do not have the same start and end point (polygon condition)
- Consideration of the stored attributes and their values (semantics)
- all building attributes, which are defined in the standard
- all generic attributes that have been added by the originator of the data (prefix: gen:)
- address data
The import can be done either via "...Surfaces" or "...Solid".
All surfaces are imported directly from the CityGML data with their geometry. The surface models have the following exclusive features:
- Geometry: minimum extrusion body (depth = 1 cm)
- Categorization: according to type of CityGML surface: Roof, Wall, Foundation, General Model (if not specified or CityGML-ClosureSurface).
- additional area attributes, if available in the data set (e.g. roof pitch or area size)
Advantages:
- possibly additional attributes
- specific categorization
- Areas can be selected and manipulated individually
- for LOD2: import usually more reliable (success rate > 98%)
Disadvantages:
- Surfaces are not geometrically connected (only apparently)
- not "waterproof" (no volume body)
- Import takes much longer, because more geometry has to be transferred (each surface individually)
- Performance of the Revit project is more stressed
All surfaces are imported directly from the CityGML data with their geometry. The solids have the following exclusive features:
- Geometry: topologically connected solid body
- Categorization: Environment
- Transfer all CityGML-Buildings and CityGML-BuindingParts as single body
Advantages:
- reduced import time
- better performance in the project
- Surfaces are connected to each other (no redundant geometry)
- "waterproof"
Disadvantages:
- possibly: missing surface attributes
- for LOD2: success rate usually worse (> 90 %). However, this depends largely on the quality of the data.
Calculation of the solids:
- Transfer of the individual point coordinates of the surfaces into topoogical vertices. This means that points no longer have to be stored redundantly and a closed body can be generated later.
- (Re)calculation of vertices via plane intersection method (intersection of 3 planes)
- If there are more than 3 planes at a corner point, an attempt is made to perform a section calculation that is as true to the original as possible. In rare cases, the calculation and transfer to Revit can lead to rough outliers.
- if the calculation fails, so-called "fallbacks" have been implemented (see parameter comments)
- original LOD2 buildings are displayed as LOD1 (extrusion of the floor plan by building height)
- if this also fails due to a faulty floor plan, a convex envelope is calculated from the floor plan coordinates, which is then again extruded by the building height
HTW Dresden - Faculty Geoinformation - Friedrich-List-Platz 1 - 01069 Dresden Project head: Prof. Dr.-Ing. Christian Clemen >>>Back to github wiki main page: here! <<< |
---|
-
Theory background:
Technical implementation:
-
for Developer: