The University of Maryland (UMD) dining halls are famous with students for their occasionally questionable array of sustenance. Trying to find nutrition information for any given meal is also notoriously difficult due to the horrendously arranged online campus dining database. That's why we're making a walkthough of creating an easily searchable dining hall nutrition database and showing how this data can be used to train an is-vegan food classifier. This will be an end-to-end tutorial covering all steps from data acquisition to generalization error estimation. Our key learning objectives are thus as follows...

1. (web scraping) get necessary nutrition facts from the UMD dining halls website
2. (data tidying) prepare scraped data for interpretation
3. (data visualization) create a read-only web database for easily querying nutrition information
4. (exploratory data analysis) examine nutritional contents and compare with health guidelines
5. (machine learning) train an "is vegan" classifier for predicting whether a given dish is vegan based off its nutrition facts
6. (analysis) apply the final classifier to predict generalization loss
7. (conclusion) key takeaways

We feel this project is relevant in that we are producing a more accessible and directly useful UMD nutrition search engine while demonstrating the end to end data lifecycle (from data collection to machine learning analysis).

Aside: dependencies¶

For the sake of this project, we will be using the requests library, BeautifulSoup, and Pandas to scrape and store data. We will create plots using matplotlib and graphviz. A searchable UI will be prepared using ipywidgets, and machine learning will be performed using scikit-learn. Nutrition data will be sourced from https://nutrition.umd.edu/, and our generalization estimation set will come from Kaggle.

Scraping the UMD dining hall nutrition data¶

Section 1: Collecting nutrition links¶

Before jumping straight into the scraping code, check out https://nutrition.umd.edu/. After a couple clicks, you might notice that the UMD dining hall web pages attempt to display a dynmaic meal page based off the query date. Since we want our database to function regardless of the current date, we can start our search from the base page for the South Campus Dining Hall (without providing any datetime information). We can then automatically pick up on the current day's meal information by grabbing each meal's current weblink (see footnote for the case that the website has gone offline or the dining halls are currently closed).

After taking care of the dynamic date query aspect, we are free to start pulling information about the foods provided for each meal (breakfast, lunch, and dinner). Each individual food item link will lead us to the nutrition facts label that we want, but these label pages do not list whether a dish is vegetarian! Instead, whether or not a food item is vegan, vegetarian, gluten free, et cetera is listed on the corresponding meal page next to each item's nutrition label link.

Because of this, we need to manually iterate through the food items table (as opposed to grabbing all relevant links with a single call to find_all()) and record the separate information about whether a dish is vegetarian or vegan. We can then cycle through each meal to copy all of our desired nutrition label links. Note that we only want to collect unique links because certain foods may be served across multiple meals. To that end, we can use a set for link storage to avoid duplicate scraping.

NOTE: because the dining halls close over break, it is entirely possible that you will NOT be able to get meal information outside of Fall and Spring semesters! If you would like to continue with this tutorial while the site is down, please download our previously generated database file from here and skip to the Data tidying section. You can then load the uncleaned dataframe prior to continuing by loading the downloaded pickle file as follows...

df = pandas.read_pickle("downloadedFile")

Section 2: collecting nutrition information¶

To actually get our nutrition data, we need to query each individual food item's nutrition label page. We can start by declaing the nutrition facts we want to grab for our new database, and then we can scrape for each of the desired nutrition label elements on a per-food-item basis.

The nutrition facts are stored in nested HTML tables using span tags, so with a bit of string parsing we can pull them directly from each food item's span tag set. We do have to grab the food name and serving size separately since they are stored in different tables. We should also keep in mind that there are a handful of food items with no nutrition data (mostly vegan dishes), so we should be careful not to query them for data which doesn't exist.

After rendering each individual nutrition fact, we can append it to the dataframe we declared earlier (loading all of the pre-defined target nutrition facts). Since this is a lengthy process and we have no gaurantee that the dining hall's websites will maintain the same format forever, we should go ahead and save our final dataframe to a pickle file for safe keeping. This will allow us to continue performing analysis and hosting nutrition data even after the dining hall webpages go offline. It's also worth noting that the nutrition data above is for a single serving of the corresponding food item (which might be measured in ounces or in numbers of the food item itself).

Data tidying: cleaning the nutrition data¶

After some poking around in the dataframe, we noticed that there are a handful of nutrition labels which simply drop nutrients that were not part of the corresponding food item (ie: grilled hotdogs do not include an entry for dietary fiber). We likewise need to account for NaN values by replacing them with a 0. We can also convert our string measurements into floats to simplify data analysis. To that end, we should grab our measurement units and store them elsewhere for later reference.

We do NOT explicitly convert serving size because it is not provided with consistent units. By this we mean that most food items have their servings measured in ounces, but others are measured in terms of individual food objects. We also leave the food name, "Is Vegetarian", and "Is Vegan" columns as-is since they are inherently non-numeric.

Note that we have chosen to use a Pandas dataframe for data storage. We reccommend using Pandas for these tasks because:

1. Pandas makes tabular data representation incredibly easy (fast queries, updates, column additions, reindexing, filtering, basic statistics, etc)
2. Pandas has incredible support across the industry (as it is the de facto standard for tabular data, we can automatically interface with HTML sources, output to SQL, interface with numpy and scipy, scikit-learn and statsmodels integrations, etc)

NOTE: we chose to load pre-scraped data at the beginning of this section for the sake of the tutorial. Having consistent meal options irrespective of current dining hall schedules makes it easier for us to provide precise examples and ascertain consistent model performance. If you are following along and would like to use more up-to-date nutriton facts, please change the indicated line from the above codeblock as follows...

df = pandas.read_pickle('umd_nutrition.pkl') # uses backup data

Should become:

df = pandas.read_pickle('new_umd_nutrition.pkl') # uses newly scraped data

Data visualization: creating a read-only web database¶

At this point in the process, we have already acquired and cleaned the desired nutrition data. With the backing dataset more or less complete, creating a database becomes trivial. For our purposes, we only want the ability to read nutrition data. Only UMD dining hall workers should be able to create, update, or delete menu items. That said, to create a read-only interface for our nutrition data, we would typically recommend bamboolib. It's the perfect tool for this sort of thing, yet we will be creating our own interface with ipywidgets for ease of HTML hosting.

Libraries aside, we want our new nutrition database to function just like UMD's: we should be able to query for whatever food we desire (by name) and get a quick nutrition facts sheet with allergens listed. To that end, we will need to define a simple string search for finding matching foods (ie. "fwench" should find "French Toast") as well as a label generation method (for outputting nutrition information). We then want to design our interface to make use of these functions for an easily searchable nutrition dataset.

We would argue that the above search box is far more convenient than looking for any given food item's nutrition information on https://nutrition.umd.edu/. That said, we realize that a search box alone is not a full-fledged database. For the sake of this tutorial we will briefly demonstrate the creation of a proper SQL database using the previously recorded nutrition information.

Also note that we are using nbinteract to embed interactive ipywidgets, so it may take some time for the backend binder to spit out results. nbinteract is also a bit buggy and sometimes duplicates the searchbox (with only one remaining functional). We would also like to point out that the simple string matching approach used in this tutorial should not be replicated for industry applications. Using Levenshtein distance with a library like fuzzywuzzy would yield far more accurate results, but the method supplied above is much easier to understand.

Aside: Creating a true CRUD database¶

A true database should implement Create, Read, Update, and Delete behavior (the CRUD standard). Since we chose to represent our data using a dataframe, we can make use of Pandas "to_sql()" method in order to create a Structured Query Language (SQL) database from our nutrition records. SQL is a common programming language for working with relational databases with many popular offshoots like SQLite and PostgreSQL, but we won't be diving too deep for the sake of this demonstration. Please refer to Usman Malik's tutorial if you would like to learn more about working with SQL in python. A simple example of creating a database and querying for cheeseburgers can be found below:

Exploratory data analysis: too much sugar and sodium?¶

The FDA's dietary guidelines recommend consuming no more than 2,300 mg of sodium a day. For men with a 2,000 calorie diet, the American Heart Association recommends no more than 36 grams of sugar per day. That being said, the UMD dining halls have to produce food en masse for the student body. With more than 30,000 undergraduate students, the University has to order frozen foods in bulk in order to feed everyone. These mass-produced foods are notorious for high sodium and sugar contents, so let's how the worst stack up to daily reccomendations...

As shown in the above graph, it is possible to exceed the reccomended daily amount of sodium and sugar intake with just two servings of dining hall food! Mixing and matching two of any of the 10 saltiest foods would put a student over the daily limit, yet two servings of the chicken noodle soup wouldn't even add up to 400 calories (leaving students to fill in the rest of their 2,000 calorie a day diet with an ideally negative portion of sodium). Sugar appears to be equally difficult to work around, but we can't say whether this pattern holds for the whole dataset just yet!

Plotting daily values vs. food contents¶

With some evidence to support that there may be far too much sugar and sodium in the average dining hall dish, let's try to see how the entire database stacks up against recommended daily values. To that end, we can compute the average nutrient content for each food in our database. We can then create a bar for the percent daily value provided by each food, and place these bars in terms of how many grams/milligrams each food was above or below the average nutrient content. To simplify the process, we can write a generic plotting function and call it with our recommended daily value for each nutrient.

For the reference data, we sourced the following daily values from usda.gov:

• Calories 2,000kCal
• Carbohydrate 275g
• Cholesterol 300mg
• Dietary Fiber 28g
• Protein 50g
• Saturated fat 20g
• Sodium 2300mg
• Total fat 78g
• Total sugars (AHA) 36g
• Vitamin C 90mg

Looking at these results, we can see that there is a large variance in what percent daily value a student can expect to receive (for any given nutrient) from each food item. Where a single serving could get you as much as 250% of your daily vitamin C, you can only get about 60% of your carbs in one go. That said, the average daily value for each nutrient also varies greatly. A student can expect to get about 10% of their daily fiber from a single serving of any random food item but only 5% of their daily cholesterol. Before delving further into classification efforts, let's look at the stats directly to see whether the high-sodium and sugar cases were just outliers...

When taken as a whole, the average sodium content of any given diner food isn't too terrible (at about 10% of the daily recommended value), but there is a very high standard deviation (of +15.2%). It would likewise be a good idea to carefully consider your options when choosing between any two food items seeing that one could contain as much as 500mg more sodium than the other.

Average sugar content similarly sits around 9.4% of the recommended daily value with a standard deviation of +16.5% DV. General statements about a high sodium or sugar content are hence difficult to prove, but perhaps we can start to see trends when we categorize the data...

Vegan or not: nutritional differences¶

With our original goal being to train a classifier for seeing whether or not a given food is vegan, it is a good idea to try breaking down our percent daily value statistics on a what-is and what-isn't vegan basis. We could then examine the averages, variance, and et cetera directly...

Looking at the above vegan vs non-vegan statistics, we can see that the vegan foods exhibited a generally lower deviation from their average contents. This can be chalked up to the lower number of vegan food entries compared to the rest of the dataset, yet the vegan food items also exhibit signficantly lower total fat, saturated fat, cholesterol, number of calories, and so on. A case could certainly be made for the benefits of going vegan within the context of the UMD dining halls, but we're more interested in whether these differences could be classified by a machine. To that end, let's try visualizing the difference in average nutrient conents between vegan and non-vegan foods with a bar graph:

As shown above, the UMD dining hall supply exhibits a significant difference in nutritional content between vegan and non-vegan foods. An apparent nutritional difference means that we could potentially train a model to recognize these differences autonomously. We can hence move on to try and train an "Is Vegan" classifier using our dining hall nutrition data!

Preparing an "Is Vegan" Classifier¶

Before we can classify foods by whether or not they are vegan, we need to make several important choices about training data and model parameters. The reason we use only certain nutrition facts to train the model is because there is not a high correlation between every nutritional fact and whether or not the food is vegan. For example, cholesterol is a great way to check if a food is vegan or not because only animal products and byproducts contain cholesterol. However, fiber and vitamin C can vary greatly with every food irrespective of whether the food item is vegan. After training a few models with different features on the UMD dining data itself, we found that we achieved the highest accuracy for vegan classification when using total fat, cholesterol, calories, sodium, and protein as the features.

Before we get into initial training, we wanted to explain the secondary reason for not using every nutrition fact: and that is the threat of overfitting. Introducing new parameters increases model complexity. This leads to a greater chance of redundancy between input features and increases the likelihood of training on features which don't have any correlation with the desired output. To that end, principal component analysis (PCA) can be used to reduce higher-order feature vectors to more manageable inputs. As this process was not necessary for our use case, we will not be discussing the topic at length; but we do recommend reading up on PCA if you plan to work with more complex models.

All that said, we can try to get an idea of what features will be most relevant to our classifier by taking a look at the correlation between each nutrition fact and whether or not a food is vegan...

Based off the above correlation coefficients, it would be a good idea to train our classifier on Total Fat, Saturated Fat, Cholesterol, Sodium, Protein, and Calories. For the sake of demonstration, we're starting with a simple decision tree model to build our classifier. Decision trees break the classification process down into a set of questions (ie. does the food have more than 10 grams of protein) and uses these questions to take an input and ascribe an output label. Decisions trees hence result in an intuitive, easy to describe model which is perfect for our tutorial. Without further ado, we can train and test a decision tree model on the UMD dining hall data to see how accurate our results are using our selected features...

The resulting decision tree is actually quite readable! Given any food's nutrition facts, it would be easy to follow along for the resulting classification. With the basic idea demonstrated, let's see if our model can actually classify vegan foods effectively. To that end, we can use the section of our split data that we did not train on (the "validation set") for testing. This approach to model training and testing is known as holdout-validation. In our case, we used 70% of the data to train on and left 30% to test with. We can then get accuracy stats as follows...

Building a better model¶

While our the previous decision tree works wonders on our UMD nutrition dataset, it might be too specific to classify non-UMD food samples accurately. Overfitting to training data often leads to this result which is commonly referred to as "generalization loss." To try and produce a model which will generalize better, we can switch to a random forest classifier (which produces a myriad of concurrent decision trees to "vote" on the best classification) instead of just a single decision tree. We can also use cross-validation (a sorts of recursive holdout-validation used to improve and test models) to demonstrate another approach to model analysis.

After running the above code several times with varying test sizes, we found that we were able to consistently achieve around 94% accuracy with our selected features using 10-fold cross validation. With our holdout validation set achieving similar results (using a 70-30 split), we were satisfied with this result and decided it was time to run our model on some non-UMD food samples.

Analysis: finding a generalization test set and cleaning it¶

To see how our classifier works in the wild, we need to get new test data. We were able to find a decent nutrition dataset on Kaggle for testing our classifier on. It contained all of the input features we had used for training, and it also provided descriptive names which we can use to manually decide if the foods are vegan. We hence begin the generalization prediction process by cleaning up this new dataset...

We can then prepare a string block list to manually classify whether or not each food is vegan for measuring the accuracy of our classifier. To keep things manageable, we can also trim our test data set down to a hundred or so entries.

Generalization error estimation¶

Now that we have a test dataset ready to go, we can start seeing how well our model does (or does not) generalize! To do so, we should call our old UMD-trained model on the external dataset. After recording our model's predictions, we can compare them with our manual vegan classifications from earlier. We can then see how accurate our model turned out to be in terms of which labels did not line up (between the predictions and manual vegan classification columns)...

After looking for mismatches between the is-vegan predictions and the labels we had created, we can see that there is some uncertainty for several foods. There is no way to know whether or not the infant formulas, chocolate milk mix, margarine, or chocolate syrup are vegan. For this reason, we have decided to drop them from our output.

After dropping the data above, we can see that we are left with four false positives of food being labeled as vegan when they are not. All of the mislabled foods are ones that contain honey. This would be difficult to accurately classify as vegan since it the only nutritional value that honey affects is sugar. We do not use sugar in our classifier since it is not generally an accurate indicator of a food being vegan, and thus we fail to classify foods that are only not vegan because of them containing honey.

We can see that our classifer generally worked well with a 96% accuracy. The only false positives are for four foods that contain honey. We have no false negatives, meaning that all food that is vegan was properly classified as such.

Conclusion¶

We have seen that creating an "is vegan" classifier using UMD dining hall nutrition facts works pretty well. Although the nutritional content of UMD dining hall food may vary from those foods that are not mass-produced, it still generalizes well. We minimized loss to the best of our ability, with the only errors in our classifier being for foods that contained honey. Honey is difficult to detect as a non-vegan ingredient because it only affects sugar content whereas most non-vegan foods have higher levels of sodium, cholesterol, protein, fat, and calories than vegan foods. It would be nearly impossible to train a 100% accurate vegan classifier without reading every ingredient for each food, and given our lack of perfect accuracy we would like to issue a word of caution for anyone using our classifier to choose their vegan meals. However, the model is likely safe for filtering out the majority of non-vegan foods, as we saw that no vegan food was accidentally labeled as non-vegan.

This project also sought to improve access to the UMD dining hall nutrition database. You no longer need to click between 10 different pages to find the nutrition facts for a particular food. The foods are also no longer separated by meal type, so it is easier to see all of the relevant data on one page. Vital allergen information for each food has also been maintained in our dataframe, and it would not be difficult to extend the present scraping to include information about whether a food is gluten-free, halal, etc.

It is also much easier to calculate one's daily nutritional intake with all of the data being provided in one place. It would also be easy to build classifiers for other diets in the future like an "is Keto" or "is low-carb" model now that the data is more accesible. Adding new foods to the UMD dining hall database is also much easier using a central dataframe in place of the dining hall's questionable web interface. It would be great to see UMD use a similar approach to nutrition data management.

Many universities use "NetNutrition" to assist in nutritional value calculations for students, and it would be nice to have a similar mechanism for tracking nutrition facts (as this is a very cumbersome process using the existing UMD dining hall web database). With such a highly-ranked computer science program, we would hope to see more user-friendly databases in use. Even though nutritional values would still need to be calculated manually, our database makes it much easier to view the facts for each food and does not require navigating through several pages for each search.