new Class RefurbishmentMeasures

[RomainNouvel]

In the Energy ADE version 0.5, information concerning possible refurbishment measures are integrated inside the _AbstractBuilding Class as two attributes: yearOfRefurbishment[Year] and refurbishmentClass[CharacterString].

The present structure does not allow to have partial RefurbishmentMeasures (e.g. only for a wall, a window or a energy system), nor several RefurbishmentMeasures for one building. Moreover, yearOfRefurbishment might be too precise, and refurbishmentClass as CharacterString is not usable in software/libraries

PROPOSITIONS:

• Create a FeatureType RefurbishmentMeasures containing the attributes DateOfRefurbishment[Date] and LevelOfRefurbishment[CodeList], which could be associate with a Cardinality [1 , 0..*] to _AbstractBuilding, _BoundarySurface, _Opening and EnergyConversionSystem for instance (any CityObject?).
• The attribute LevelOfRefurbishment could be a hierarchical multi-lingual CodeList (use Re3gistry developed by jrc), referring for instance to the Refurbishment variants "Standard" and "Advanced" defined in the European Projekt Tabula, or to any other local refurbishment variant, provided that it is defined somewehere (in a library or a document, whose reference should be indicated with the LevelOfRefurbishment)

[JoachimBenner]

I agree in case a generally accepted CodeList for the levelOfRefurbishment is available.

[PRemmen]

agree with Joachim, for Germany we could for example add the different EnEV standards to this codelist

[Fouly]

• per our last discussion, I agree. refurbishment should be enabled to any building part in general. I'd say to any CityObject, as Romain mentioned above.
• In case of applying dateOfRefurbishment attribute, I think it might also be better that we've it in a separate class or maybe even allowing for date range, since it's sometimes hard to determine the exact date of refurbishment (we had the same debate on the yearOfConstruction).

[RomainNouvel]

Experience from practical use: RefurbishmentMeasures assigned to _Opening and EnergyConversionSystem make no sense, since someone has the detailed information, that a window, respectively a energy conversion system, has been exchanged, he will rather actualize the _Opening construction and the EnergyConversionSystem with the new ones, than use the class RefurbishmentMeasures...

For this reason, I would delete the attributes RefurbishmentMeasureOnOpening of the class _Opening and RefurbishmentMeasureOnEnergySystem of the class EnergyConversionSystem introduced at the end of last year.

[oliviertournaire]

Implemented in latest version of the UML model