If you enjoy OpenStreetMap or StreetComplete, you should also have a look at OpenFoodFacts: https://world.openfoodfacts.org/ -- it's the same thing, but for cataloguing food.
You can scan the food that you have laying around the house (via the website or app), or help fix information about existing products by answering questions based on other people's photo uploads: https://hunger.openfoodfacts.org/
These are all new to me.
What's the idea behind open data like this?
It's unclear to me why anyone would need a directory of food products.
@srfirehorseart A big part of open data is precisely that it doesn't need to be built for any one specific usecase - the data is provided in a generic, unopinionated format and then it's up to people what to do with it. Including in ways you might not have foreseen.
For OpenStreetMap, common usage includes (of course) mapping/navigation applications (there's a good chance you've used something that uses OSM data!), but also directories of opening times, disability aids (where is the nearest bench, wheelchair access), and so on.
For OpenFoodFacts, the data is often used to quickly look up the nutritional values of products (beyond what is already on the packaging), to compare nutrition levels in different options, as an extra safeguard against allergens, and so on.
But undoubtedly there are many usecases I'm unaware of for both of them - that's the nice thing about open datasets :)
@srfirehorseart @joepie91 A few years ago I dabbled with the database export but realised it was too large:
https://world.openfoodfacts.org/data
Even the CSV export can take considerable amount of time to download.
But they have almost 3 million entries if I recall correctly.
Yes, it makes sense that those many records would take a long time to download, unless you have a lot of computing power.
Also, I noticed a warning that you'd need a complete dataset to exclude out of date information.
"Please note that due to the nature of mongoexport, the delta files cannot tell you about deleted products. To remove deleted products from your database, you will need to import the full MongoDB dump."
@srfirehorseart @joepie91 Personally I don't like MongoDB very much.
I'd much rather a relational database, since most of the headers overlap anyway.
Given the site, analysis of the whole database could happen in Google BigQuery (yikes! Google) or a Jupyter notebook.
I'm not aware of anyone having tried that.
@srfirehorseart @RyunoKi (Note that there is also an RDF export, and a couple other files)
@srfirehorseart They definitely track where the food is available, and you can filter by this - but the UI is certainly something that needs to be improved. I think the expectation for casual users is to mainly use it by scanning individual products (and in the Netherlands, I'd say I've had about a 70% success rate with that, despite it being a very obscure site here).
Ultimately it *is* going to be primarily crowdsourced, and that means there's a certain amount of fuzziness to the data that's unavoidable. But within that, they track revisions, ask people to make pictures of the packaging as a data source, they extract expiry dates to associate data with production dates, and so on.
@joepie91
Maps: That makes sense for the application of map data. Location data usually takes years to change.
Food: Maybe I missed it but, at first glance, all I saw was a list of mainly French products.
Food products puzzle me, as I didn't see an obvious filter by location, etc. As a UK user, I'd want to see produce available in the UK.
With all kinds of data, I'd want to see some careful data management, otherwise it risks losing relevance over time.