cstb / citygml-energy

CityGML Energy ADE
40 stars 9 forks source link

Clarification of attribute "buildingType" #105

Closed JoachimBenner closed 7 years ago

JoachimBenner commented 8 years ago

The ADEElement _AbstractBuilding has an attribute buildingType, defined as

Classification of building according with their usage and form (e.g. single-family house, multi-family house, office building, industrial building).

I thik that a usage classification and a form classification are two different topics which should not be mixed. For the usage classification, there already exist two attributes in the CityGML base standard (function - originally intended building function; usage - actual building usage). Thus, I think the attribute buildingType should only define a form typology. In this context, is the actually existing Codelist BuildingType really adequate?

RomainNouvel commented 8 years ago

The original purpose of the Attribute buildingType is to refer to building typology categorisations of building physics libraries (like Tabula). buildingType should not contain only residential-related building types (multi-Family houses etc.), and should not relate directly to building usage (however, the building physics is linked in a way to the building usage requirements, for instance in the case of Office building glass towers or jails). It would be great to collect some standard examples of non-residential building types (e.g "Office building tower")

JoachimBenner commented 8 years ago

I can imagine that there are many different typology sytems available. If a simulation system wants to use a buildingType for, e.g., deriving default values of specific properties, the used typology system (e.g. Tabula) should be known. Therefore, I propose to introduce an additional (CodeList-) attribute "buildingTypologySystem", and to encaplulate both attributes (buildingTypologySystem and buildingType) in a complex attribute.

gioagu commented 8 years ago

Very good idea. I agree.

RomainNouvel commented 8 years ago

Good idea but concretely, it does not exist standardized "buildingTypologySystem". It depends actually on the modeller and its building library. For instance, in HFT we combine the Tabula Building types for residential buildings and our own building types for non-residential buildings. Maybe giving a url for the source of the building type categorisation (e.g online-publication or website) would be sufficient...

JoachimBenner commented 8 years ago

No additional attribute needed, CodeList registry must provide the information.

oliviertournaire commented 8 years ago

What is the status of this issue? I move it into the backlog milestone ...

gioagu commented 7 years ago

Just a reminder, how is the current status? I believe we agreed on the values expected in this attribute, but is the naming still the same? Instead of building_type, should we go for something like

building_typology or building_archetype?

which "echoes" a bit more what Tabula and similar approaches do?

pgcipriano commented 7 years ago

Actually, according to the comment by @RomainNouvel on April 15 "buildingType should not contain only residential-related building types (multi-Family houses etc.), and should not relate directly to building usage". I do agree with him. At the moment in the <> class BuildingTypeValue we have 5 values, only referring to residential buildings. Similarly, in the GeoSmartCity codelist register we have a "buildingType" codelist only containining the 4 values from Tabula (http://hub.geosmartcity.eu/registry/codelist/BuildingTypeValue/).

I suggest to (1) update the list of values of "BuildingTypeValue" codelist defined in the Energy ADE, and (2) populate/update the GeoSmartCity codelist accordingly, with both labels and definitions provided in English as well as other national languages (at least German, French, Italian).

About the values, we might also look at the "buildingNature" codelist defined by INPSIRE (http://inspire.ec.europa.eu/codelist/BuildingNatureValue), focused more on the architectural characteristics of buildings than on the usage.

JoachimBenner commented 7 years ago

I propose to close this issue and continue the discussion in issue #140

RomainNouvel commented 7 years ago

ok