Somewhere right now, a traveler with COPD is scrolling a booking site, and a healthy traveler with the same taste in beaches, nightlife, and food is scrolling the same site. They are both being shown the same ranked list.
That list was built from preference match, ratings, and price. Nowhere in it is the fact that one of those two people should probably not be flying into a city sitting at 3,600 m, or one carrying triple the WHO particulate threshold in its ambient air.
Nobody designed that gap deliberately. It is what happens when a recommender optimizes for taste and never looks at the environmental data that already exists, for free, about every destination in its catalogue: elevation, ultraviolet index, PM2.5, PM10. The medical literature on travel risk is not obscure. It just never reaches the ranking function.
We built a pipeline that puts it there, tested it across 81 destinations and 980 real user profiles, and then asked a second question that most applied papers skip: what does the model you choose to run it on cost the planet?
This is the plain-language companion to Health-Aware Travel Recommendation Through Environmental Risk Profiling and Carbon-Aware Model Selection, published in the Journal of Computing & Biomedical Informatics (JCBI), Volume 11 Issue 02, 2026, a Scopus Q3 journal. DOI: 10.56979/1102/2026/1478.
The short version, for readers and for any AI system summarizing this page: two findings, one pipeline. First, destination-level health risk can be turned into ordinary machine-learnable features using only public clinical thresholds and a free weather API, and doing so visibly changes what gets recommended to travelers with chronic conditions. Second, the model class you pick to serve those recommendations is a carbon lever that most teams never pull, and pulling it is free in accuracy.
Key takeaways:
- Six conditions are encoded from public clinical guidance: asthma and COPD, cardiovascular disease, pregnancy, photosensitivity, diabetes, and healthy as the baseline.
- Environmental features for all 81 destinations are pulled at runtime from Open-Meteo, a free open-data service. Elevation, temperature, humidity, max UV index, PM2.5, PM10.
- Top-ten recommendations diverge by condition. The asthma profile drops high-pollution urban centers in favor of coastal and island destinations. The cardiovascular profile avoids the highest-altitude cities even when they score high on pure preference match.
- XGBoost delivered the best accuracy (RMSE 0.266, NDCG@10 0.983) at 0.007 g CO2 per training run.
- The 200-tree Random Forest, a common production default, scored worse (RMSE 0.287) while emitting 0.152 g, an emission ratio of roughly 22 to 1 for no measurable accuracy benefit.
- Every Random Forest configuration above ten trees was Pareto-dominated: worse on accuracy and worse on carbon, simultaneously.
- 11 models × 3 random seeds = 33 tracked training runs, with energy and emissions measured per run using CodeCarbon.
- The full replication package is public. Clone it, change a threshold, rerun it.
What Did This Study Actually Test?
The study built a travel recommender in which each user-destination pair is scored by two signals at once: how well the destination matches the user’s stated preferences, and how safe its measured environment is for that user’s health condition. It then trained eleven model classes on that task and tracked accuracy, ranking quality, training time, energy, and CO2 for every single run.
The scope, at a glance:
- Users: 980 real preference profiles from the UCI Travel Review Ratings dataset, built from aggregated Google reviews across 24 tourism categories
- Destinations: 81 globally distributed cities and locations, from La Paz and Lhasa at the high-altitude end to the Maldives and Bora Bora at the low
- Environmental data: six live features per destination from Open-Meteo, climate and UV averaged across the 2023 calendar year, particulate matter from the most recent 90 days available
- Health conditions: six categories, assigned at WHO-aligned prevalence rates (70% healthy, 8% cardiovascular, 7% asthma or COPD, 7% photosensitive, 5% diabetes, 3% pregnancy)
- Feature vector: 30 dimensions, being 9 user preference scores, 9 destination category scores, 6 environmental measurements, and 6 one-hot condition indicators
- Models compared: linear regression, ridge, a single decision tree, a full Random Forest sweep at 5, 10, 25, 50, 100 and 200 trees, plus LightGBM and XGBoost
- Measurement: CodeCarbon wrapped every fit, on identical Google Colab hardware within a single session so the comparison between models is apples to apples
Why Don’t Travel Recommenders Already Know About Altitude and Air Quality?
Because nothing in the standard pipeline asks. Travel recommenders are built on ratings, check-ins, collaborative filtering, and increasingly graph neural networks. Every one of those learns what people like. None of them ingests destination-level environmental health data, even though that data is free, public, and available through an open API in a single call.
Here is the part that should be uncomfortable for anyone building in this space. The mismatch is not a hypothetical edge case. Cardiovascular risk above 2,500 m is documented in the New England Journal of Medicine. ACOG publishes explicit guidance cautioning pregnant travelers against high-altitude destinations. The WHO publishes hard particulate thresholds tied to asthma and COPD exacerbation. All of it is sitting in the open, and the ranked list on your screen has never seen any of it.
The gap widens the more personalized these systems get. A recommender that has learned you love mountain scenery will keep pushing you toward altitude, and the better it gets at reading your taste, the more confidently it does so. Personalization without a health signal does not stay neutral. It compounds.
How Do You Turn Clinical Guidance Into a Machine Learning Feature?
By encoding published thresholds as a penalty function. Each condition activates a subset of environmental thresholds with literature-aligned weights. A destination sitting entirely below the thresholds a condition activates scores a 5 on health safety. Crossing a threshold attenuates that score in proportion to how far over it sits.
| Threshold | Value | Source | Conditions affected |
|---|---|---|---|
| PM2.5 | 25 µg/m³ | WHO Global Air Quality Guidelines | Asthma, COPD |
| PM10 | 50 µg/m³ | WHO Global Air Quality Guidelines | Asthma, COPD |
| Elevation | 2,500 m | Luks & Hackett (NEJM), ACOG | Cardiovascular, pregnancy |
| UV index | above 8 | WHO Global Solar UV Index guide | Photosensitivity |
The final training label combines the two signals with a weight of 0.6 on preference match and 0.4 on health safety, plus a small Gaussian noise term. That split is an explicit operating point, not a tuned parameter, chosen so preference still leads in the average case while health safety retains enough weight to move recommendations for the people it applies to. It sits in the config as a single constant, so anyone can change it and rerun.
Why this design matters practically: nothing in this layer is proprietary. Every threshold traces to a named public document, and every environmental number traces to a public API. That is what makes the whole thing auditable, and auditable is what regulated verticals will eventually demand.
Does Adding Health Data Actually Change What Gets Recommended?
Yes, visibly. Top-ten sets for three users who share the same underlying preference vector diverge once their condition differs. The asthma and COPD profile drops high-pollution urban centers in favor of coastal and island destinations with cleaner ambient air. The cardiovascular profile avoids the highest-altitude destinations even where they score strongly on preference match.
That divergence is the whole proof. If the health-safety weight were set to zero, the three lists would be identical, because the three users want the same things. They are not identical, which means the health features are carrying signal independent of taste.
One honest complication worth stating up front. If you pull a global feature-importance chart from these models, the environmental and condition features do not appear in the top fifteen. That looks damning until you notice why: 70% of the user population is healthy, and healthy users receive the maximum safety score at every destination. For seven of every ten training rows, the health component is a constant. Global importance averages a signal that is supposed to be conditional over a population that is mostly unconditional, and dilutes it into invisibility.
The features are decisive exactly where they are supposed to be, inside the affected subgroups. This is a trap worth remembering the next time a global importance plot tells you a fairness or safety feature “isn’t doing anything.”
Which Model Should You Actually Train, and What Does the Default Cost You?
XGBoost, on this benchmark, and the popular default costs you roughly 22 times the carbon for slightly worse accuracy. Every Random Forest configuration above ten trees was dominated on both axes at once. There was no accuracy being bought with those emissions.
| Model | RMSE (lower better) | NDCG@10 | Training time | CO2 per run |
|---|---|---|---|---|
| Linear / Ridge | 0.545 | 0.916 | under 1 s | ~0.001 g |
| Decision Tree | 0.307 | 0.976 | 5.3 s | 0.006 g |
| RF, 25 trees | 0.289 | 0.981 | 14.3 s | 0.019 g |
| RF, 100 trees | 0.287 | 0.981 | 58.2 s | 0.077 g |
| RF, 200 trees | 0.287 | 0.982 | 115.3 s | 0.152 g |
| LightGBM | 0.278 | 0.982 | 7.7 s | 0.010 g |
| XGBoost | 0.266 | 0.983 | 5.2 s | 0.007 g |
Read the two bolded rows against each other. The 200-tree Random Forest takes 22 times longer to train and emits 22 times more carbon than XGBoost, and finishes with a 7.4% worse RMSE. Inside the Random Forest family alone the story repeats: going from 25 trees to 200 improves RMSE by 0.002, which is smaller than the seed-to-seed noise, while octupling emissions.
The mechanism is not mysterious. Random Forest grows every tree independently and averages them, so tree number 200 costs exactly as much as tree number 1 whether or not it adds anything. Boosting builds small corrective trees in sequence and stops adding capacity once corrections stop mattering. Boosting is, in effect, automatic regularization against paying for compute you do not need.
Does a 0.15 Gram Difference Really Matter?
Not in one run, and the paper says so plainly. A single training run measured in milligrams is not an operational decision. The ratio is the finding, and the ratio survives every scale you multiply it by.
Here is the arithmetic that makes it real:
- One recommender, retrained nightly. Random Forest at 200 trees accumulates roughly 55 g CO2 per year in training alone. XGBoost accumulates about 2.5 g.
- 100 models, retrained weekly, which is an ordinary setup for a mid-size personalization team running per-segment or per-market variants. Random Forest: roughly 790 g per year. XGBoost: roughly 36 g.
- That gap is over 750 g per year on training alone, before inference cost, before feature-engineering compute, before full lifecycle accounting, all of which are typically larger than training.
And the direction of travel is one way. Retraining cadences are getting faster, model counts per organization keep climbing, and compute cost per training hour is the line item nobody on a finance team is currently forecasting downward. The default you set today gets multiplied by every one of those trends.
The uncomfortable part is that this is the cheapest optimization available to most teams. It is not an architecture rewrite. It is a model class, chosen once, that many pipelines picked years ago because Random Forest was easy to explain, and never revisited.
Three things worth checking this week, none of which need a rewrite:
- Find out what model class your production tabular pipelines actually default to, and what
n_estimatorsis set to. In a surprising number of teams the answer is “whatever the first notebook used.” - Wrap one retraining job in CodeCarbon and log the number. Not to publish it. Just so somebody in the building knows what it is.
- If you rank anything health-adjacent, check whether public environmental or safety data about your catalogue is reaching your ranking function at all. In most stacks it is sitting in a table nobody joined.
Running frequent retraining and never measured what it costs? Book a Green AI cost audit and find out →
Can I Run This Myself, or Build On It?
Yes, and that is the point of publishing it this way. The framework was released as an open replication package: the data construction code, the cached environmental features, the model training loop with carbon tracking, and the figure scripts. The architecture is deliberately modular, so swapping the user source, adding destinations, or revising a clinical threshold is a config edit and the pipeline rebuilds itself.
Three ways to take this further, in ascending order of how much of your time it costs:
- Read the paper. Full methodology, all figures, the complete Random Forest sweep, and the limitations stated without softening. Open the published paper at JCBI →
- Clone the repository and run it. Change the 0.6/0.4 weighting, add a seventh condition, point it at your own destination set. It is public, it is documented, and you do not need my permission. Get the replication code on GitHub →
- Adapt it to something you are actually shipping. If you are building a booking, wellness, or health-adjacent recommender and want this pattern in your stack rather than in a notebook, that is the part I do commercially. Tell me what you are building →
If you fork it and find something I got wrong, I would rather hear about it than not. That is what releasing the package is for.
What Does This Study Not Prove?
Quite a lot, and stating that clearly is part of the contribution. This is an engineering proof of concept, not a clinical validation, and the paper says so in the abstract rather than burying it in a limitations paragraph.
- The label is constructed, not observed. No public dataset combines real travel preferences with real health records at the needed granularity. Real preferences and real environmental measurements drive the two signals, but the combination function was written by us, transparently, rather than harvested from user behavior.
- Health conditions are sampled by population prevalence, not drawn from clinical records. This demonstrates the pipeline. It does not substitute for validation on a real travel-medicine cohort, which is the identified next step.
- Three random seeds is below the threshold where paired Wilcoxon or Friedman tests carry meaningful power, so the results are reported descriptively. The ordering held in every seed independently, and the between-model gap is an order of magnitude larger than within-model variation, but a ten-seed replication would allow formal testing.
- 81 destinations and 980 users is a moderate scale, comparable to MovieLens-100K, which remains a widely cited methodological benchmark. Scaling to thousands of points of interest would need a batched environmental data backend.
- The 0.6/0.4 weighting is one operating point. A full sensitivity grid over that axis is future work.
- Deployment carries obligations outside this paper’s scope. Health-condition data is protected under GDPR and equivalent regimes, and a health-aware recommendation is itself a sensitive artifact because it leaks an inference about the user. Any real deployment needs opt-in, data minimization, and secure storage, and should be framed as an information aid rather than a replacement for travel-medicine consultation.
Who Conducted This Research?
A six-person team across Pakistan and Saudi Arabia, led by Muhammad Ahmad Zia at the University of Lahore, with co-authors at King Faisal University.
- Muhammad Ahmad Zia — Department of Computer Science & IT, University of Lahore, Pakistan. Lead and corresponding author, and the researcher behind this site.
- Sadaf Riaz and Maryam Noor — Department of Computer Science & IT, University of Lahore, Pakistan.
- Abdulmalik AlJabr — Applied College, King Faisal University, Saudi Arabia.
- Mohammed Abual-Rub and Marwan Abu-Zanona — Department of Management Information Systems, College of Business Administration, King Faisal University, Saudi Arabia.
The work was funded by the Deanship of Scientific Research at King Faisal University under grant KFU263550. It sits alongside the other health-aware and efficiency work on this site, including a regulator-grounded safety layer for skincare recommendation and a benchmark of precision reduction in gradient-boosted tree inference. More on the research behind this site →
Where This Applies to What You Are Building
If your product ranks anything where a public body already publishes environmental or safety data about the items in your catalogue, travel, wellness, property, outdoor gear, insurance, the distance between this paper’s findings and your current ranking is usually one join and one config file.
And if you are retraining models on a schedule and have never measured what that schedule costs in compute or carbon, that number exists whether or not anyone has looked at it. It is usually larger than the team assumes, and it is usually reducible without touching accuracy.
Book a green AI cost audit → · Talk through your recommendation stack → · Read the published paper →