add Mandatory Units of Measure

[RomainNouvel]

List of units of measure should be mandatory (for instance: m2 and not m² nor sqm).
Check if we can use standard list of units / uri. How do we deal with it in GML

[JoachimBenner]

Such a list can cannot be defined in the UML diagram or in the XML-schema, and with XML-schema technology alone it it impossible to restrict the uom names/URLs in use. This means that at the moment the list of feasible uom names is just a text document which can be stored in the guidelines. For later versions of the Energy ADE, we can think about technical solutions for checking the uom-restrictions, e.g. additional conformance rules.

[oliviertournaire]

@RomainNouvel @JoachimBenner Can we close this issue? The work is not yet finished, but maybe we can add something in the guidelines pointing to the XLS definitions file?

[RomainNouvel]

We definitly need a discussion with you the XML experts and WP leaders about this. I would suggest to keep this unsolved issue open.

[JoachimBenner]

There are three main issues to be discussed:

1. For which physical properties uom-identifieres are needed?
2. Which identifiers are used for the basic SI units? Do we directly take the SI codes, or do we simplify the system by, e.g. only using small letters?
3. What is the methodology to generate uom-identifiers for complex, derived physical units like the UValue

In the Excel tabel I make some proposals as basis for the discussion. In my methodology, the uom of a UValue is "wm-2k-1".Giorgio made another proposal, which would read "W/(K*m^2)"

UnitNames.xlsx

[mlauster]

We should be comliant with ISO 1000-1992, what still keeps open some details about combining units.

[mlauster]

ISO 1000-1992 has been revised by ISO 80000-1:2009

[mlauster]

Ideas for a proposal:

• Stick to SI units where possible (e.g. W instead of kW)
• Capital letters according to ISO 80000-1:2009
• Keep them in alphabetical order and try to avoid negative exponents

Still needs some revision

[JoachimBenner]

This issue has no influence on the data model itself. The list of uom-labels shall be published in the guidelines or as separate document.

[mlauster]

Is this proposal fine for everbody? We could then set up a list of typical UoMs.

[RomainNouvel]

Do we stick to the format "wm-2k-1" or "W/(K*m^2)", then? We've said that the second one was easier to read I think...

[mlauster]

Jep, the second one. :)

[oliviertournaire]

Can we add something in the guidelines and once done, close this issue?

[mlauster]

At https://github.com/cstb/citygml-energy/blob/issue65_UoM/doc/guidelines/Guidelines_EnergyADE.md I added a first version of such a table. Could you please review this table, give comments if this a sufficient solution or what to modify and add further units?

[JoachimBenner]

Hello,

I would suggest also to include the uom identifiers of the Si units into the table, at least:

Length – m
Mass – kg
Energy – J

In some cases, I would allow different physical dimensions for the same quantity:

Angle: rad (radian) and deg (degree)
Mass: g (gram) and kg (kilogram)
Temperature: C (degree Celsius) and K (degree Kelvin)
Energy: J (Joule) and kWh (Kilowatt hours)
Power: W (Watt) and kW (Kilowatt)
Time: s (second) and h (hour)

I think, the physical dimension of an infiltration rate is “volume per time”, i.e. m^3/h or m^3/s.

We must clearly distinguish between “Thermal Conductivity” (also denoted as k- or λ-value), and the “Thermal Transmittance” (also denoted as U-Value). The Thermal Conductivity is a real material parameter with dimension W/(m_K), the U-Value is a parameter of a specific building element (wall, roof, …) with dimension W/(m^2_K). The “Thermal Resistance” (or R-Value) of a building element is the inverse of the U-value with dimension (K*m^2)/W.

Best regards

Joachim

---

Dr. Joachim Benner
Karlsruher Institut für Technologie (KIT)
Institut für Angewandte Informatik
Herrmann-von-Helmholtz-Platz 1
Bau 445, Raum 337
76344 Eggenstein-Leopoldshafen

Tel.: +49 (0)721 608 22534
Fax: +49 (0)721 608 25786
E-Mail: [email protected]:[email protected]

From: Moritz Lauster [mailto:[email protected]]
Sent: Monday, October 31, 2016 2:42 PM
To: cstb/citygml-energy
Cc: Benner, Joachim (IAI); Mention
Subject: Re: [cstb/citygml-energy] add Mandatory Units of Measure (#65)

At https://github.com/cstb/citygml-energy/blob/issue65_UoM/doc/guidelines/Guidelines_EnergyADE.md I added a first version of such a table. Could you please review this table, give comments if this a sufficient solution or what to modify and add further units?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com//issues/65#issuecomment-257296154, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AGId_HbjjciLxHe-ugyE6L-SOuLujPM5ks5q5fAegaJpZM4GsRZX.

[gioagu]

Hi!

I agree with Joachin, besides we should take into account also other time units, such as yeas (a) which is commonly used for yearly energy demand amounts (total or specific) kWh/a - kWk/(a*m^2).

For monthly values, note that there is no standard symbol for week or month. These units should therefore always be spelled out in technical writing, e.g. kWh/(m^2*month)

Regarding the (sub)multiples, I would simply stick to the allowed SI prefixes (k, M, T, etc.).

Greetings

G

[RomainNouvel]

Hi,
year and month are used (almost?) only for indicators (yearly heating demand etc.) ... that we agree to not include in the Energy ADE during our workshop in Munich. Instead we use time series with all useful information (related year, precise start and end date etc.).
So normally, we do need neather month nor year as unit...

[mlauster]

I agree with @RomainNouvel, we should limit our choices of time intervals, in particular week and month are difficult objects as they are not clearly defined throughout all applications and month varies from month to month in it's length, so we would need to know which month was chosen.
Regarding SI units, I agree, we should add the related ones to the list, the current list is a first draft to start with, feel free to add other units or modify the existing ones.

[JoachimBenner]

Decided by Energy ADE plenum at December 6th, 2017: A list of feasible uom identifiers, together with a general description of an uom-identifier syntax, will be included into the documentation of Version 1.0