Open RomainNouvel opened 8 years ago
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.
@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?
We definitly need a discussion with you the XML experts and WP leaders about this. I would suggest to keep this unsolved issue open.
There are three main issues to be discussed:
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)"
We should be comliant with ISO 1000-1992, what still keeps open some details about combining units.
ISO 1000-1992 has been revised by ISO 80000-1:2009
Ideas for a proposal:
Still needs some revision
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.
Is this proposal fine for everbody? We could then set up a list of typical UoMs.
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...
Jep, the second one. :)
Can we add something in the guidelines and once done, close this issue?
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?
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: joachim.benner@kit.edumailto:joachim.benner@kit.edu
From: Moritz Lauster [mailto:notifications@github.com] 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/cstb/citygml-energy/issues/65#issuecomment-257296154, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AGId_HbjjciLxHe-ugyE6L-SOuLujPM5ks5q5fAegaJpZM4GsRZX.
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
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...
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.
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
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