-
Notifications
You must be signed in to change notification settings - Fork 17
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Building decomposition #8
Comments
My understanding: buildingpart is a building but not a top-level-feature: it is a physical subdivision belonging to some top-level building. It is also a building. buildingunit is a set of spaces associated with a building and has identifying properties that allow grouping into functional units. storey is a special kind of buildingunit that is distinguished because it is likely to be used a lot. This all makes sense to me, although I find the case for buildingpart to be weak. But maybe I am not thinking of the critical use case. I think part of the semantic confusion stems from the naming of the classes. In particular, it would help to have the last word of a compound word be the name of the underlying class. Assuming that I have the above correct, would it make sense to change the class names to make the representation function of the classes more obvious? buildingpart could be named subbuilding or subordinatebuilding to indicate both that it is not a top-level feature and that it is a building. buildingunit could be called logicalsubdivision or logicalunit to clearly indicate its function and to make it clear that it is not a building. |
In the Modelling Subgroup we agreed that we need to include in the specification a detailed description of the three concepts and give clear recommendation when to use which concept. We will create a drawing showing the differences of the concepts. In addition, we will try to get feedback from the CityGML SWG group at the next OGC meeting in Singapore on these concepts. |
I also still struggle with the BuildingPart, although it is clear now that it is a full-featured Building, with all attributes of Building, e.g. roof type, as opposed to a BuildingUnit. But then, if you have BuildingParts with all these attributes, would the aggregation of these parts need to have these same attributes again? If so in which cases? Otherwise, if the aggregated Building would merely be a group of BuildingParts without its own attributes, then why not model it as a group of Buildings or just let the CityModel play the role of the aggregator? |
WHAT IS THE NEED FOR BUILDING PARTS? – A COMPARISON OF CITYGML, INSPIRE BUILDING AND A SWEDISH BUILDING STANDARD https://www.int-arch-photogramm-remote-sens-spatial-inf-sci.net/XLII-4-W10/27/2018/ |
just as an example of a CityGML profile as discussed today at the SWG meeting. It defines how building / building part are used in Germany on city models generated by the state survey (LoD2, fully automized process based on 2D cadastral plans). The 3D model product spec on state level. Municipalities usually have more detailed models. Unfortunately in german, but your may use google translate or another translation software. And the validation plan to validate the 3D models. |
Buildings with 'parts' that are stacked on top of each other are common. As an example, we can consider Pacific Place in Hong Kong There is a podium with multiple towers, and the space ontop of the podium is a space that is accessible to the public. The towers are each separate buildings. The location of the ground plane is quite ambiguous since there are multiple levels that feel like the ground. The actual ground is somewhere deep down under the underground car parking levels. Another example might be the Marina Bay Sands in Singapore. The concepts of building, building part, building unit, storey, do not seem to fit very well for these types of building. It seems that the current definition of building part is that it must be in contact with the ground. In hight density cities, the groundplane is often a very ambiguous concept, so it is not clear if something is in contact with the ground. Originally posted by @phtj in #58 (comment) |
It is also important to remember that the vast majority of LOD2 building models that have been or are being created in (semi-)automatic processes are based on 2D building footprints and photogrammetry or airborne lidar. If at all, building parts are created in these processes based on subdivisions that are modelled in the footprints. If the footprints are not subdivided, then it is rather hard to automatically identify building parts based on changes over height in this input data. |
In the modelling subgroup there was broad agreement that the vertical stacking of building parts should be allowed in CityGML 3.0 to support the provided examples. Building parts should therefore no longer be required to touch the ground. To avoid confusion, more precise definitions and descriptions have to be provided in the specification for the different semantic concepts. Like It was also proposed to keep the name A remaining open question is whether, in case building parts are modelled, the embracing |
In the web conference on 4 April 2019 we discussed the question whether geometry is only allowed to occur on the building parts when a building consists of several building parts, or whether there are cases that require the embracing building to have geometry as well. The links below provide examples that seem to require the building itself to have geometry. The buildings exhibit specific building installations that cover several building parts and cannot be assigned to one specific building part only.
We discussed that from a software implementation point of view it would be useful if only building parts need to be processed and not the building itself to find out whether also the building contains geometry. We came to the agreement that when a building consists of several building parts, no geometry is being attached to the building itself, but only to the building parts. Installations that are spanning across several building parts are to be physically modelled as part of one building part, all other building parts reference the installation using XLinks, expressing in this way, that the installation does not exclusively belong to one building part only. |
What is the difference of building parts, building units, and building storeys and their intended usage? Am I understanding it correctly, that a building can be subdivided into parts once and after that ad libitum into storeys (horizontal subdivision) and units (vertical subdivision) in an alternating way? If so, the building part definition seems redundant, but probably I am missing something.
The text was updated successfully, but these errors were encountered: