Open aleene opened 7 years ago
hangy
commented
7 years ago I get the idea but that also sounds a bit redundant. The 100 g value should be superfluous if good values for ie. a 175 g portion are provided, and vice-versa. If the calculated value for 100 g (for comparison purposes) differed from the 100 g value on the packaging, then the question would be: What's the correct value and which one is used for the nutriscore and to calculate averages for the categories?
aleene
commented
7 years ago It sounds indeed redundant. I encountered the issue, as my app allows to change both simultaneously (which is not possible in the api).
Maybe the question should be elevated to another more fundamental one. The OFF-api and web-interface now offer a mix of original and interpreted (calculated) values. So it is a mix of data on the package and deduced data. Maybe OFF should more explicitly distinguish between the two types of data to be more clear. Anyway allowing to create both nutriment values, corresponds better to the OFF-idea: data on the package only.
Checking values on the pacjkage is a bit the purpose of OFF?
hangy
commented
7 years ago Checking values on the pacjkage is a bit the purpose of OFF?
True! 👍 But if we allow both values to be entered, the question on which value should be used for comparison purposes does need to be addressed. Also, I've seen energy, carbs, fats and proteins for portions (ie. on the front) and for 100 g in the nutrition table.
Having both values from the packaging in the DB would allow us to issue warnings if there's a larger difference between packaging 100 g value and 100 g calculated from portion size.
The write api now only supports either values per 100 g or per serving. Allow both (needs other keys), so a user can set values per 100 g and per serving, when both are available on the package.
Allows an additional check on what is found on the package.