"Building" and "BuildingUnit" as subclasses of a more generic concept "Construction"

In the last session we had some discussions where the outcome was not entirely satisfactory for me: -parking lot as a BuildingUnit, whereas parking space is not (I understood that parking lot is like a floor full of parking spaces) -the relation between Building and BU, especially for a plain 1-household house, where you need both concepts in order to be able to give it an address -AddressableObject that was left out I was also missing some elements that I think belong to a building such as rooms, floors, ...

After some reflection, I'd like to propose the following model: Construction

Most of the classes in this model are subclasses of a generic "Construction" class ; these constructions can be added together to form more elaborate constructions. Thus a (complex) building could be made up of -appartments -offices -parking lots -parking space -floors -rooms ... A house could be made up of -rooms (living room, kitchen, bath room, sleeping room, ..) -a roof -a basement -a garage -a swimming pool -a garden shed ...

Buildings and BuildingUnits would be "Constructions" as well as "AddressableObjects", meaning they can have an official Belgian address attached to them.

Hope this helps for the discussion.

In INSPIRE-Building there is indeed a class Construction. But only mentioned as superclass of a Building/OtherConstruction/Installation. Only for InteriorInstallation the word Construction appears in the definition, but no explicit inheritance of Construction. Neither for BuildingUnit or Room, only for BuildingPart (of which the definition does not allow it to be used for Rooms etc). I would indeed advise to add Construction as (hidden) superclass of Building, but only Building.
Only BuildingUnits (and CadastralParcels) are addressable according to BestAdd and its Address assigning rules. Addressable means: eligible for the official assignment of an Address. Unofficial assignment (eg bij derivation of the Address of the BuildingUnits of the Building or via the CadastralParcel) is allowed and we have an attribute for it, not with datatype Address but with datatype AddressRepresentation.
CommonSpace is a special case of BuildingUnit. By means of the attribute BuildingUnit.function you can make a disctinction between appartments, garages etc and common space.
Room is a class in INSPIRE-Building. But it is not defined as a subclass of Construction. There is a 0..* association from Building and BuildingUnit with Room. Attributes are geometry and roomNature. Not sure if it is necessary to add this to ICEG-Building, INSPIRE only includes Rooms in the 3D level4 application profile (the current ICEG-Building model only includes levels 1 and 2).
Things like a basement, a swimming pool (interior), a garage are BuildingUnits if they have an entrance from outside or from a common space, otherwise they are just Rooms.
Things like a garden shed, a swimming pool (exterior as a seperate building), a garage are Buildings if they are seperate from other Buildings. A minimal surface surveying criterion may apply. So: implicitely they are in the model. The large scale map of Flanders makes a distinction between MainBuilding and AnnexBuilding to easily seperate out official from other Buildings (an official Building having BuildingUnits with an official Address).
About Roof: this is included in the 3D level2 application profile of INSPIRE Building, Superclass is BoundarySurface and other subclasses are among others: RoofSurface, WallSurface, OuterFloorsurface etc. It is a Building that can be bounded by all these kind of surfaces. These surfaces have a geometry at least and an association with possible openings (Doors, Windows). They are not considered as being Constructions by INSPIRE.
For Floors there is an object in INSPIRE-Building that is called Floordescription. But not with very usefull attributes. Why would you like to add it? Things like on which level a BuildingUnit can be found and so on are included in AddressRepresentation.
It might be possible to think of ParkingLots or ParkinSpaces as Constructions but these objects are not to be found in INSPIRE-Building and also seem to be out of scope then for ICEG-Building in my opinion. That said, a ParkingSpace could be considered a Room if it is distinguishable. A ParkingLot is a collection of ParkingSpaces, has nothing to do with Building I think, rather with Parcels or Usage.

Marc, Geert

Thank you for your input on this.

First and foremost, our apologies for not taking this with us to the previous webinar. We didn’t integrate this issue because our preparation for the webinar was already closed when it was posted.

-parking lot as a BuildingUnit, whereas parking space is not (I understood that parking lot is like a floor full of parking spaces) It might be possible to think of ParkingLots or ParkinSpaces as Constructions but these objects are not to be found in INSPIRE-Building and also seem to be out of scope then for ICEG-Building in my opinion. That said, a ParkingSpace could be considered a Room if it is distinguishable. A ParkingLot is a collection of ParkingSpaces, has nothing to do with Building I think, rather with Parcels or Usage.

The definition of a building unit is indeed broad enough to include a parking lot. When there is a parking lot, you can indeed have different parking spaces. When they are separate from each other they are building units. If not, they are considered part of a parking lot. The ‘rights’ of individual parking spaces is a use case for Parcels. This means that parking can be modeled in the proposed model.

-the relation between Building and BU, especially for a plain 1-household house, where you need both concepts in order to be able to give it an address -AddressableObject that was left out Only BuildingUnits (and CadastralParcels) are addressable according to BestAdd and its Address assigning rules. Addressable means: eligible for the official assignment of an Address. Unofficial assignment (eg bij derivation of the Address of the BuildingUnits of the Building or via the CadastralParcel are allowed and we have an attribute for it, not with datatype Address but with datatype AddressRepresentation.

In the current model a building can have a zero-to-many relationship with building units. It is not necessary for a building to have building units. Based on the discussion during the webinars it was proposed to implement an address both for building and building units. That is also the reason not to use addressableObject, but addressRepresentation instead as this makes it possible to cater for this use case and allows to also assign an address to a building.

In INSPIRE-Building there is indeed a class Construction. But only mentioned as superclass of a Building/OtherConstruction/Installation. Only for InteriorInstallation the word Construction appears in the definition, but no explicit inheritance of Construction. Neither for BuildingUnit or Room, only for BuildingPart (of which the definition does not allow it to be used for Rooms etc). I would indeed advise to add Construction as (hidden) superclass of Building, but only Building. Most of the classes in this model are subclasses of a generic "Construction" class ; these constructions can be added together to form more elaborate constructions.

Thanks for this suggestion. What might be the advantages of having a separate entity for Construction? Is there anything that is not yet covered without the use of Construction? This will be taken to the next webinar for discussion, but other opinions are also welcome within this thread.

Things like a basement, a swimming pool (interior), a garage are BuildingUnits if they have an entrance from outside or from a common space, otherwise they are just Rooms. Things like a garden shed, a swimming pool (exterior as a seperate building), a garage are Buildings if they are seperate from other Buildings. A minimal surface surveying criterion may apply. So: implicitely they are in the model. The large scale map of Flanders makes a distinction between MainBuilding and AnnexBuilding to easily seperate out official from other Buildings (an official Building having BuildingUnits with an official Address).

It is not always the case that basements, swimming pools (interior) etc are BuildingUnits. Sometimes these are just part of building. For example in a house these are not necessarily BuildingUnits. When these things are separate from a Building, indeed for example a garden shed, they are indeed a separate building. We will look into the possibility of having a relation between 2 buildings and discuss this during the next webinar.

About Roof: this is included in the 3D level2 application profile of INSPIRE Building, Superclass is BoundarySurface and other subclasses are among others: RoofSurface, WallSurface, OuterFloorsurface etc. It is a Building that can be bounded by all these kind of surfaces. These surfaces have a geometry at least and an association with possible openings (Doors, Windows). They are not considered as being Constructions by INSPIRE. Room is a class in INSPIRE-Building. But it is not defined as a subclass of Construction. There is a 0..* association from Building and BuildingUnit with Room. Attributes are geometry and roomNature. Not sure if it is necessary to add this to ICEG-Building, INSPIRE only includes Rooms in the 3D level4 application profile (the current ICEG-Building model only includes levels 1 and 2).

The roof is included in the 3DGeometry LoD2. In fact, the interior of a building can be modeled via 3DGeometry LoD4. For this issue, I would like to refer you to the issue on Geometry.

Thus a (complex) building could be made up of -appartments -offices -parking lots -parking space -floors -rooms CommonSpace is a special case of BuildingUnit. By means of the attribute BuildingUnit.function you can make a disctinction between appartments, garages etc and common space.

Indeed, this is addressed by using buildingUnits with their according functions. For this case, we need to look into the codelist for function and possibly expand this with additional function types. At the moment we have following: individualResidence, collectiveResidence, twoDwellings, moreThanTwoDwellings, residenceForCommunities, agriculture, industrial, office, trade, publicSerivces and ancillary.

For sure we will take this input with us in modeling ICEG building and to the next webinar.

There is clearly a need to add some info about functionality like ParkingSpace, SwimmingPool and so on. But:

There is no need to introduce these as classes in a domain that is about Buildings. Reason is that they are not always Buildings/BuildingUnits/Rooms and so as a class they would belong to another domain. If you model them as a class, do this in another domain and use double typing on the occasion they are indeed a Building/BuildingUnit/Room.
Also, the fact that they are like Buildings a Construction is not a valid reason. INSPIRE uses Construction as the superclass of Building but does not give a proper definition. But it is clear that the definition is very broad and something like "something that has been build or put together". It could be a poem for that matter.
Actually INSPIRE uses the Construction superclass to be able to include objects to a data exchange while at the same time saying that they are not Buildings. They use the classes OtherConstruction and Installation for that. It is to avoid that someone types a exterior SwimmingPool as a Building just to be able to add it to the data collection.
Another reason INSPIRE uses Construction as a superclass is that its subclasses have some attributes in common like dateOfConstruction, elevation and so on. So: if we include the subclasses mentioned in point 3 or to prepare for it in the future and to be in line with INSPIRE introducing it as a (hidden) superclass would be a good idea.
And otherwise: just by means of attributes like building(unit)functionality there is already a lot that can be said about how the building(unit) is used. Attention: which is different from building(unit)nature which says what type it is (house, castle, shed and so on). I would also include this one as an attribute.

My original comment was not made with the Construction superclass of INSPIRE in mind. Probably I should give that class another name. The intention was to introduce a kind of "lego-block" that could be aggregated together with other "lego-blocks" to form more elaborate "things". Ultimately they would lead to BuildingUnits and Buildings.

Floor was just given as an example: up to the working group to decide what "legoblocks" are needed in the model, if there would be an interest in such model.

Thank you for the input Geert and Marc. Construction is indeed seen as an abstract concept overseeing building and building unit.

What we are modeling here is a building (unit) and its intrinsic values, not a construction. We agree to the notion of an abstract super class, but won’t model it as out of scope (see also the charter). Regarding the naming, it’s a superclass so we still need Building on a less abstract level.

For sure we will take this input with us in modeling ICEG building and to the next webinar.

This issue will be considered closed as this was considered out of scope for this model during one of the previous webinars.

belgif / thematic

"Building" and "BuildingUnit" as subclasses of a more generic concept "Construction" #87