building-envelope-data / api

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

Add BSDF resources #249

Closed christoph-maurer closed 2 years ago

christoph-maurer commented 3 years ago

I got feedback from software companies that they are interested in using BSDF data from IGSDB.

@StephenCzarnecki How do you estimate the effort to add resources in the LBNL/Klems XML format to the components which have such data? I have created the dataFormatId e021cf20-e887-4dce-ad27-35da70cec472 .

StephenCzarnecki commented 3 years ago

@christoph-maurer Do you mean to just add a url to download the XML data as another resource in the metadata? I do not think that will be difficult. However I would first like to describe the current implementation in the IGSDB so everyone can have the same understanding.

In the current IGSDB implementations (both igsdb.lbl.gov and igsdb-icon.herokuapp.com) if a product has a bsdf xml file it is available under the IGSDB REST api like /api/v1/products/{igsdb_id}/datafile.

For example in igsdb-icon.herokuapp.com the manufacturer Glen Raven has a product named "FF 4603-0000" that is represented by a bsdf. This has an IGSDB ID of 13321 (and for reference a CGDB ID of 10057). And it has some information available at https://igsdb-icon.herokuapp.com/api/v1/products/13321. However the BSDF XML data is available at https://igsdb-icon.herokuapp.com/api/v1/products/13321/datafile

Is the proposal for bsdf products to have a second resource in the metadata with the /datafile url? So the above product would have two resources, one with locator https://igsdb-icon.herokuapp.com/api/v1/products/13321 and a second with locator https://igsdb-icon.herokuapp.com/api/v1/products/13321/datafile dataFormatId that corresponds to "LBNL/Klems XML" (e021cf20-e887-4dce-ad27-35da70cec472)

A quick note: https://igsdb-icon.herokuapp.com/api/v1/products/13321/?json_format=buildingenvelopedata.org throws a 500 error from the server. This is because the product is not a glazing product. Only glazing products have been translated to the ICON json format. So this product is hitting an error somewhere in the process of serializing to the ICON format which should get resolved during work on serializing shading layers.

christoph-maurer commented 3 years ago

@StephenCzarnecki Thanks for the note and the explanations!

Is the proposal for bsdf products to have a second resource in the metadata with the /datafile url? So the above product would have two resources, one with locator https://igsdb-icon.herokuapp.com/api/v1/products/13321 and a second with locator https://igsdb-icon.herokuapp.com/api/v1/products/13321/datafile dataFormatId that corresponds to "LBNL/Klems XML" (e021cf20-e887-4dce-ad27-35da70cec472)

That's exactly what I was hoping for.

christoph-maurer commented 3 years ago

@StephenCzarnecki asked:

@christoph-maurer Can you provide an example of how this example using IGSDB ID 13321 would look like as a GetHttpsResource? I still do not think I am completely clear how this structure should work.

christoph-maurer commented 3 years ago

I'll try the following example: I query https://www.buildingenvelopedata.org/graphql/ with

query{
  databases{
    nodes{
      uuid
      name
      locator
      allOpticalData(where: {componentId: {equalTo: "78a03d86-8ddd-4aef-8f17-2989f4b3b5f5"}}){
        nodes{
          uuid
          resourceTree{
            root{
              value{
                locator
              }
            }
          }
        }
      }
    }
  }
}

for all optical data sets of this component with the IGSDB ID 13321. In the future, I could get a response like

  "data": {
    "databases": {
      "nodes": [
        {
          "uuid": "48994b60-670d-488d-aaf7-53333a64f1d6",
          "name": "IGSDB",
          "locator": "https://igsdb-icon.herokuapp.com/icon_graphql/",
          "allOpticalData": {
            "nodes": [
              {
                "uuid": "b8c21c24-ffbf-46f1-a205-997cffe7db48",
                "resourceTree": {
                  "root": {
                    "value": {
                      "locator": "https://igsdb-icon.herokuapp.com/api/v1/products/13321"
                    }
                  }
                }
              },
              {
                "uuid": "0f3e045f-8964-41b0-9fe4-8b1e9e745809",
                "resourceTree": {
                  "root": {
                    "value": {
                      "locator": "https://igsdb-icon.herokuapp.com/api/v1/products/13321/datafile"
                    }
                  }
                }
              }
            ]
          }
        }
      ]
    }
  }

This means that the nearnormal optical values and the BSDF are two separate optical data sets of the same component. A resourceTree is helpful if you have the same data in various formats. Then, you can define the original, root resource and which resources were derived from it.

christoph-maurer commented 3 years ago

@StephenCzarnecki Do you think it is possible to implement the BSDF files and the dataFormatId until August 24? @simon-wacker could then implement it into metabase on August 25 before he is out of office for three weeks. The feature would be very helpful in our discussions with software companies about a follow-up project.

StephenCzarnecki commented 3 years ago

I have updated https://igsdb-icon.herokuapp.com/ to add the ability to return metadata for BSDF xml files in ICON graphql queries. Products with a BSDF XML file now return two results, one for the the json_format=buildingenvelopedata.org json and one for the BSDF XML file. For example this query

query {
  allOpticalData(
    where: {  componentId: {
      equalTo: "f1b368d3-faaa-402a-98e2-14edf47adb6e" } }
  ) {
    nodes {
      uuid
      resourceTree {
        root {
          value {
            description
            hashValue
            locator
            formatId
          }
        }
      },
      nearnormalHemisphericalVisibleTransmittances
    }
  }
}

Returns this response:

{
  "data": {
    "allOpticalData": {
      "nodes": [
        {
          "uuid": "c7061a4c-80f0-4917-8722-bc5a0f062b42",
          "resourceTree": {
            "root": {
              "value": {
                "description": "IGSDB glazing data",
                "hashValue": "aa6339c0b5aea8d6bae48904666d6b03f5e1fa574a70deb36ee94f18113f93b6",
                "locator": "https://igsdb-icon.herokuapp.com/api/v1/products/13619/?json_format=buildingenvelopedata.org",
                "formatId": "061b5664-4c49-404a-a597-a6bad39b3001"
              }
            }
          },
          "nearnormalHemisphericalVisibleTransmittances": [
            0.012295,
            0.012295
          ]
        },
        {
          "uuid": "eae76839-94da-4909-a36f-fa7c85ebb501",
          "resourceTree": {
            "root": {
              "value": {
                "description": "LBNL/Klems XML",
                "hashValue": "14eadfbbe0b5796d6b6a6f989b8adc8fae192d99ba9221c0e8b0a181eff5edb0",
                "locator": "https://igsdb-icon.herokuapp.com/api/v1/products/13619/datafile/",
                "formatId": "e021cf20-e887-4dce-ad27-35da70cec472"
              }
            }
          },
          "nearnormalHemisphericalVisibleTransmittances": [
            0.012295,
            0.012295
          ]
        }
      ]
    }
  }
}

I also checked performance by doing a query for all records with nearnormalHemisphericalVisibleTransmittances in the range [0, 1] and did not hit the heroku timeout which is good.

Let me know if there is anything that should be changed or if you run into any performance issues.

christoph-maurer commented 3 years ago

Thank you, @StephenCzarnecki ! This is very helpful.