building-envelope-data / api

API specification to exchange data about building envelopes
MIT License
3 stars 1 forks source link

Definition of component characteristics #46

Open simon-wacker opened 4 years ago

simon-wacker commented 4 years ago

In GitLab by @simon-wacker on Aug 13, 2020, 14:17

In the definition componentCharacteristics of the schema opticalData.json,

  1. the properties treatmentBefore, locationOnSample, and polarizationSensitivity, referenceSample, spot, and definitionOfSides are references, where a reference is either a standard or a publication (where publication need not be a scientific one). Can one really not be more precise in the schema (why can't I for example not use coordinates to specify the location on the sample)? Do I really need to publish a website somewhere to specify that I used the top-left corner as location on the sample (which would be problematic if the website went down or changed its domain; it's also not machine readable)? Or are there already ISO or other standards for such locations? What are the answers to similar questions regarding the other properties?
  2. the property normalization is an array with, in particular, the two possible properties relative and absolute. This makes it possible to use the value ["relative", "absolute"] for the key normalization. Does this make sense? What would be the meaning of such a normalization?
simon-wacker commented 4 years ago

In GitLab by @christoph-maurer on Aug 13, 2020, 18:21

  1. This is unfortunately an area with not enough standardization. We know only one standard for BSDF. It’s ASTM E2387 stored at P:\600\groupdrives\620_eeb\621_sbe\Aktuell\Wissensbasis_fuer_die_Gruppe\Normen_Richtlinien\ASTM\ASTM_E_2387-05\ASTM E2387-05_reapproved_2011_mitTexterkennung.pdf. It provides the bullet points “treatmentBefore”, “locationOnSample”, “polarizationSensitivity”, “referenceSample” and “spot”, but fails to define how they should be described. They probably think of human-readable text. “definitionOfSides” is not even mentioned in ASTM E2387. However, it’s crucial, because samples have neither front nor back, top, bottom, left or right. In general, it can be mounted in any orientation. The current state of science is (sadly) that an employee attaches a label close to the edge of the sample and that the label is used to define the “prime” and “nonPrime” surface of the sample. By the way, Helen Rose plans to improve the English of these terms and the descriptions in the branch improving-the-examples. The label is also used to define top, bottom, left, right. If the sample can be mounted only in one orientation, usually this is used.

I have difficulties to define the coordinate system for the location of the sample in general. For rectangular samples, the corner with the label may be used. Often there are several samples of one component with different dimensions for different test facilities. Therefore, the center of the sample may be suited better, but it is very important for the measurements, you cannot scratch it measuring distances accurately. When the sample has periodic patterns, often two optical measurements are used: one with a hole in the center and one with the material between two holes in the center. In this case, two photos of the location of the spot would be much more helpful than coordinates.

There are some documents like the photogoniometer manual of Peter Apian-Bennewitz, which describe some things well and are preferred by our lab. My hope was that the scientific community tends to agree on the boundary conditions and their description. That Bruno and Helen Rose write a journal paper about this topic which can serve as reliable reference.

  1. Thank you for finding this mistake! Please delete the array and make it only an enumeration of the four strings. It should not be possible to use more than one of them. They refer to four methods to normalize and are described in ASTM E2387.
simon-wacker commented 4 years ago

Note that point 2. was resolved in commit https://github.com/ise621/building-envelope-data/commit/d35c6b784c527dfad209b35f4ab9d80b99e6b42e.

christoph-maurer commented 3 years ago

Regarding 1., we have currently no better solution. Regarding 2., the mistake was corrected.

simon-wacker commented 3 years ago

I reopened it because even if we do not have a better solution at the moment it is still an open issue and should be considered once in a while (if it is closed it looks like it has been fixed). I'm unsure right now whether we should close it and have a special label, or keep it open and have a special label. For the time being I would use the second option (but it's just a gut feeling).