search

building-envelope-data / api

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

Mirror more values to facilitate the search #233

Closed christoph-maurer closed 2 years ago

christoph-maurer commented 3 years ago

In addition to nearnormalHemisphericalVisibleTransmittances, gValues and uValues, we believe it would be good to mirror as well nearnormalHemisphericalVisibleReflectances, nearnormalHemisphericalSolarTransmittances, nearnormalHemisphericalSolarReflectance, infraredEmittance, the colour rendering index CRI and the CIELAB colour parameters L*, a*, b*.

@StephenCzarnecki Would this be possible after the implementation of the new JSON format?

christoph-maurer commented 3 years ago

In order to illustrate how the new values to be mirrored look like according to the JSON Schema, I have created examples:

StephenCzarnecki commented 3 years ago

@christoph-maurer I'm not sure I understand exactly what you are requesting here. Here are some thoughts based on what I currently understand, please correct me where I am mistaken.

From what I understood before the "mirrored" values are those values that can be returned by the GraphQL metadata query. And so far at least those values do not really have anything to do with the ICON JSON schemas.

Using nearnormalHemisphericalVisibleTransmittances as an example:

In the database.graphql file there is type OpticalData which has the following:

  """
  Mirrored nearnormal hemispherical visible transmittance values that occur in
  the data
  """
  nearnormalHemisphericalVisibleTransmittances: [Float!]!

And there nearnormalHemisphericalVisibleTransmittances is just an array of floats. It does not seem to have anything to do with the ICON JSON schemas. Is that Float type going to be changed into something else, specifically a dataPoint from schemas/opticalData.json?

Also is the intent to expand the OpticalData type in database.graphql to look like the following?

  """
  Mirrored nearnormal hemispherical visible reflectance values that occur in
  the data
  """
  nearnormalHemisphericalVisibleReflectances: [Float!]!

  """
  Mirrored nearnormal hemispherical solar transmittance values that occur in
  the data
  """
  nearnormalHemisphericalSolarTransmittances: [Float!]!

  """
  Mirrored nearnormal hemispherical solar reflectance values that occur in
  the data
  """
  nearnormalHemisphericalSolarReflectances: [Float!]!

  """
  Mirrored infrared emittance values that occur in
  the data
  """
  infraredEmittances: [Float!]!

  """
  Mirrored CRI values that occur in
  the data
  """
  cri: [Float!]!

  """
  Mirrored Lab values that occur in
  the data
  """
  lab: [?!]! # Not sure what the type should be here, seems like either it should be a 3-tuple or some other defined type

If so then should the float values be something else?

Also if these values are being added to the mirrored data should they also be added to the list of things that can be queried for? E.g. should OpticalDataPropositionInput be changed to look like this?

input OpticalDataPropositionInput {
  componentId: UuidPropositionInput
  and: [OpticalDataPropositionInput!]
  nearnormalHemisphericalVisibleTransmittance: FloatPropositionInput
  nearnormalHemisphericalVisibleReflectances: FloatPropositionInput
  nearnormalHemisphericalSolarTransmittances: FloatPropositionInput
  nearnormalHemisphericalSolarReflectance: FloatPropositionInput
  infraredEmittance: FloatPropositionInput
  cri: FloatPropositionInput
  lab: NotYetDefinedPropositionInput
  not: OpticalDataPropositionInput
  or: [OpticalDataPropositionInput!]
}

Finally just a note: I do not think the IGSDB has CRI.

christoph-maurer commented 3 years ago

Thank you for your questions, @StephenCzarnecki !

  1. A child database like IGSDB stores the opticalData as a JSON resource for HTTP GET requests and the metadata about a data set for the GraphQL queries. In the JSON resource, the nearnormal-hemispherical visible transmittance looks like

    "dataPoints": [
{
"incidence": {
"direction": {
"polar": 8
},
"wavelengths": { "integral": "visible" }
},
"emergence": {
"direction": "hemispherical"
},
"results": {
"reflectance": 0.1
}
}
]

    You can write a script which searches for this pattern and mirrors these values in the float array nearnormalHemisphericalVisibleTransmittances which is used for the GraphQL queries. It's an array so that it can contain the optical data for the prime and for the nonPrime surface (front and back in IGSDB). We assume that the user is interested in components which have at least one surface with a value of nearnormalHemisphericalVisibleTransmittances in the range she is interested in.

  2. Yes, it is the intent to expand the OpticalData type in database.graphql to look like the following:

    
"""
Mirrored nearnormal hemispherical visible reflectance values that occur in
the data
"""
nearnormalHemisphericalVisibleReflectances: [Float!]!

""" Mirrored nearnormal hemispherical solar transmittance values that occur in the data """ nearnormalHemisphericalSolarTransmittances: [Float!]!

...and so on...

Only the CIELAB parameters L*, a*, b* would have to be mirrored individually like

""" Mirrored CIELAB parameter L that occurs in the data """ Lstars: [Float!]! """ Mirrored CIELAB parameter a that occurs in the data """ aStars: [Float!]! """ Mirrored CIELAB parameter b* that occurs in the data """ bStars: [Float!]!


3. If `nearnormalHemisphericalVisibleReflectances`, `nearnormalHemisphericalSolarTransmittances`, `nearnormalHemisphericalSolarReflectance`, `infraredEmittance` are easy to implement, but `CRI` and `L*`, `a*`, `b*` are difficult to implement, we could agree to implement only the first four this year.

4. I'm sorry, I don't understand the question "If so then should the float values be something else?" Can you please rephrase it?

5. Yes, as these values are being added to the mirrored data, they should also be added to the list of things that can be queried for.

6. Yes, the OpticalDataPropositionInput should be changed to look like this:

input OpticalDataPropositionInput { componentId: UuidPropositionInput and: [OpticalDataPropositionInput!] nearnormalHemisphericalVisibleTransmittance: FloatPropositionInput nearnormalHemisphericalVisibleReflectances: FloatPropositionInput nearnormalHemisphericalSolarTransmittances: FloatPropositionInput nearnormalHemisphericalSolarReflectance: FloatPropositionInput infraredEmittance: FloatPropositionInput cri: FloatPropositionInput Lstar: FloatPropositionInput aStar: FloatPropositionInput bStar: FloatPropositionInput not: OpticalDataPropositionInput or: [OpticalDataPropositionInput!] }


I have changed only the part about the Lstar, aStar and bStar.

7. Was I able to answer your questions? Also further questions are highly welcome!
christoph-maurer commented 3 years ago

I must correct myself: If we decide to include the CIELAB parameters, we would create a new type in the GraphQL specification which has three keys Lstar, aStar and bStar, something like

type CIELABparameterSet {
  Lstar: Float!
  aStar: Float!
  bStar: Float!
}
StephenCzarnecki commented 3 years ago

@christoph-maurer Thanks

Just to clarify a bit for your first point

A child database like IGSDB stores the opticalData as a JSON resource for HTTP GET requests and the metadata about a data set for the GraphQL queries.

This isn't really how we've been implementing the IGSDB. At least not so far. The IGSDB stores data in a set of tables in a postgres database. Those tables are accessed by creating models in django. Prior to ICON we had a method for creating json (lets call this IGSDB-json) from those tables. Because we had just developed the database structure in parallel with the json format those two things have a close, but not exact, relationship.

Now for the ICON work we are not changing the structure of the postgres tables except to add fields required by ICON like uuid. What we have been doing is creating functionality that allows IGSDB to respond to process ICON metadata queries and respond by creating ICON-metadata-json from the data in the existing structure. And likewise we are working on creating a resource url that contains ICON-data-json, for lack of a better term.

I just want to clarify this since it doesn't seem to quite match what you say. And also in case you see any issues with it or have any suggestions.

That being said I have updated igsdb-icon.herokuapp.com/icon_graphql to have support for nearnormalHemisphericalVisibleReflectances, nearnormalHemisphericalSolarTransmittances, nearnormalHemisphericalSolarReflectance, infraredEmittance. But not CRI or L*, a*, b*.

I have not included CRI or L*, a*, b* because the IGSDB does not currently have those values and I would like to clarify issue #239 first.

Two things:

  1. The graphql library we are using depends on the graphql schema file. So the IGSDB is using an updated version of database.graphql to support these new values. How would you prefer to look at these changes and decide if you wish to incorporate them? I was thinking I can just fork this repo and do a pull request. But if there is a different workflow you would prefer, or if you would prefer to make and commit the changes yourself instead, let me know.
  2. There was some inconsistency with singular vs plural in the new fields. I tried to go with how the existing nearnormalHemisphericalVisibleTransmittance seems to work: singular in the query and plural in OpticalData E.g.
query {
  allOpticalData(
    where: {  
      nearnormalHemisphericalVisibleTransmittance: {greaterThanOrEqualTo: 0.5}
      nearnormalHemisphericalVisibleReflectance: {lessThanOrEqualTo: 0.7} 
      nearnormalHemisphericalSolarTransmittance: {greaterThanOrEqualTo: 0.3}
      nearnormalHemisphericalSolarReflectance: {lessThanOrEqualTo: 0.7}
      infraredEmittance: {lessThanOrEqualTo: 0.9}
    }
  ) {
    nodes {
      nearnormalHemisphericalVisibleTransmittances
      nearnormalHemisphericalVisibleReflectances
      nearnormalHemisphericalSolarTransmittances
      nearnormalHemisphericalSolarReflectances
      infraredEmittances
    }
  }
}

But that can easily be changed.

Again this has only been lightly tested so if you find any issues let us know.

christoph-maurer commented 3 years ago

Thanks a lot for your clarification, @StephenCzarnecki ! I should have deleted "A child database like IGSDB stores the opticalData as a JSON resource".

With Pull Request #238 , I am currently implementing nearnormalHemisphericalVisibleReflectances, nearnormalHemisphericalSolarTransmittances, nearnormalHemisphericalSolarReflectances, infraredEmittances into the API specification. I think the use of singular vs. plural now fits to your example. Do you agree?

I propose that we wait with the implementation of ColorRenderingIndex, Lstar, aStar and bStar into the API specification until at least one child database is able to return such data. But based on the discussion of ise621/metabase#72 , I think it would be helpful that the users could include the dataFormat into their DataPropositionInput. I will make a proposal in #238 and ask @simon-wacker to review it.

simon-wacker commented 3 years ago

@StephenCzarnecki Regarding

I was thinking I can just fork this repo and do a pull request. But if there is a different workflow you would prefer, or if you would prefer to make and commit the changes yourself instead, let me know.

Yes, that's the preferred workflow for contributions (for this contribution Christoph was quicker in making a pull request). If you wish, I can also give you write access to this repository, which would make contributions from you a bit easier.

christoph-maurer commented 2 years ago

This issue was solved by #238.