search

building-envelope-data / api

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

Allow more keys in graphql queries #238

Closed christoph-maurer closed 3 years ago

christoph-maurer commented 3 years ago

I have added nearnormalHemisphericalVisibleReflectance, nearnormalHemisphericalSolarTransmittance, nearnormalHemisphericalSolarReflectance and infraredEmittance to the API specification. If these values are contained explicitly in the resource of the optical data set, then programmers should also be able to use them in graphql queries. Examples of how these values can be represented in the resources can be found here.

I have added cielabColor and colorRenderingIndex to the API specification and rearrange them in the schemas.

I have also added the formatId of a dataFormat to the DataPropositionInputs so that it can be used in graphql queries.

Relates to #233 and ise621/metabase#72

christoph-maurer commented 3 years ago

@simon-wacker Currently, color is used in component/characteristics and in photovoltaics for the subcomponents. Is this the best solution or would you prefer to have color as an additional subschema of opticalData? If color remains a property of component/characteristics, I would implement it in graphql accordingly.

christoph-maurer commented 3 years ago

I have discussed the changes with @simon-wacker and I have implemented them accordingly.

christoph-maurer commented 3 years ago

I've closed the pull request by mistake.

christoph-maurer commented 3 years ago

Why did you move the definition of color from common.json to opticalData.json when the definition is also used and needed in photovoltaicData.json?

From my point of view, color is now part of the domain optical. It is still used in photovoltaicData.json to define the colors of subcomponents which may not have their own identifier. But the color of the module is now defined in opticalData.