cstb / citygml-energy

CityGML Energy ADE
41 stars 9 forks source link

add Mandatory Units of Measure #65

Open RomainNouvel opened 8 years ago

RomainNouvel commented 8 years ago

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 commented 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.

oliviertournaire commented 8 years ago

@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 commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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

mlauster commented 8 years ago

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

mlauster commented 8 years ago

Ideas for a proposal:

Still needs some revision

JoachimBenner commented 8 years ago

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 commented 8 years ago

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

RomainNouvel commented 8 years ago

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 commented 8 years ago

Jep, the second one. :)

oliviertournaire commented 8 years ago

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

mlauster commented 7 years ago

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 commented 7 years ago

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.

gioagu commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 6 years ago

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