EcoTrip Planner

Compare estimated carbon, time, and cost across travel modes in India—so a lower-carbon journey starts with an informed choice.

Comment

Inspiration

A trip starts with choices: how much it costs, how long it takes, and how to get there. Its climate impact often remains invisible until those choices have already been made.

EcoTrip Planner brings that missing dimension into the decision itself. It helps people exploring travel within India ask a practical question: “For this journey, what could a lower-carbon option look like—and what trade-offs would I make?”

The Earth Forward connection is direct: use technology to make environmental consequences understandable before an everyday decision. Rather than asking travelers to interpret a spreadsheet of emissions factors, EcoTrip connects a familiar itinerary to a visual comparison they can explore.

But awareness is only the first step. The longer-term vision is to connect informed choices with responsible incentives: help people understand a lower-carbon option, then explore rewarding them for actually completing it. That is the motivation behind the proposed EcoCredits roadmap—not a claim that rewards already exist.

What it does

EcoTrip is a working Streamlit application for comparing illustrative travel scenarios across Train, Bus, Car, and Flight.

A traveler enters supported Indian cities, journey dates, a primary mode, traveler count, and hotel nights. The app calculates estimated total and per-person emissions, separates transport from accommodation, and compares alternative modes using emissions, indicative cost, and estimated duration. Charts and an illustrative map help explain the result.

The comparison keeps the question consistent: the same travelers and journey-leg scope are used for each alternative. A return journey doubles transport—not hotel nights. Unchanged accommodation is excluded from transport-savings comparisons.

A concrete example: in a recorded Delhi–Mumbai scenario for three travelers traveling one way, the model estimated 154.28 kg CO2e by train versus 879.45 kg CO2e by flight for transport. That is 725.17 kg, or 82.5%, lower in this modeled comparison. With two hotel nights, the selected train itinerary totaled about 334.3 kg CO2e, including 180.0 kg for accommodation.

These are outputs from the prototype’s assumptions—not measured journeys, universal reduction rates, or carbon credits. Availability, schedules, and fares are not verified.

How we built it

The supported calculation path uses Python, Streamlit, local Indian-city data, and deterministic geographic and emissions heuristics. Pandas and Plotly support analysis and charts; Folium and streamlit-folium provide the map; geopy supports geographic distance calculations.

The core transport calculation is:

Estimated emissions = modeled one-way distance × illustrative emissions factor × travelers × journey legs.

Accommodation is calculated separately using hotel nights and traveler count. Mode-specific distance and factor assumptions make each comparison reproducible. The current engine is explainable and requires no external API keys for calculations; it is not a trained machine-learning model.

Calculation, geographic validation, comparison, and presentation are separated into components. Session handling preserves a submitted result until the traveler explicitly recalculates. Automated regression tests and Streamlit workflow tests support reliability, and the public deployment has been exercised through real browser interactions.

The estimation engine does not depend on live routing APIs. The hosted interface and map tiles still require internet access; this is not an offline-installable mobile app.

Challenges we ran into

The hardest problem was making a comparison that remained meaningful when a trip changed. Return journeys, multiple travelers, and hotel nights can produce convincing-looking but incorrect totals if their scopes are mixed. The revised calculation contract keeps those quantities explicit and compares alternatives on a transport-only, like-for-like basis.

Another challenge was graceful failure. An unsupported city should not quietly become a plausible route, and a form edit should not silently change a saved result. Input validation and explicit submission make those behaviors predictable.

Finally, the interface needed to communicate uncertainty as clearly as it communicated numbers. Distances, durations, fares, and emissions are estimates. The map connects city coordinates; it is not navigation geometry. Being clear about those boundaries is part of building a useful climate tool.

Designing the future EcoCredits concept raises a further challenge: rewarding a real change without encouraging inflated baselines, duplicate claims, or unnecessary extra travel. The proposed safeguards address those risks; they have not yet been implemented or validated.

Accomplishments that we're proud of

A publicly accessible app with an end-to-end itinerary, calculation, comparison, chart, and map workflow.

Corrected traveler-count, round-trip, and accommodation handling, backed by regression and interface tests.

More than 190 automated tests passed in recorded local testing; the public app was also checked separately in a browser.

A calculation path that works without external API credentials, reducing setup barriers for a prototype demonstration.

A clear distinction between what the product demonstrates today and what still requires validated data, field testing, and partnerships.

The project demonstrates a decision-support workflow—not proven behavior change or verified emissions reductions. No user-adoption or realized environmental-impact claim is being made.

What we learned

The central engineering lesson is that sustainability software needs a trustworthy comparison before it needs a more impressive label. Units, baselines, journey legs, and occupancy assumptions can matter more than adding an “AI” badge.

Testing the interface also revealed problems that pure calculation tests can miss: state persistence, recalculation behavior, and map rendering all affect whether a user can understand and trust the result.

For the next stage, estimation and evidence must remain separate. A planned trip is not a completed trip, and an estimated reduction is not a certified offset. An incentive should recognize meaningful choices without disadvantaging people who already travel sustainably. Those lessons shape the proposed verification, privacy, and fairness safeguards for EcoCredits.

What's next for EcoTrip Planner

EcoCredits: from an informed choice to a repeatable habit

A calculator can reveal a better option; a well-designed incentive could help make that choice repeatable. The proposed next chapter is EcoCredits: non-tradable reward points for completed lower-carbon journeys. This extends the Earth Forward ambition from making emissions visible to testing whether responsible incentives can support sustained behavior change.

Status: proposed design—not implemented functionality or a promised launch. Journey verification, rewards, redemption, and offset transactions do not exist in the current app.

The proposed journey: Compare → Choose → Verify → Reward

Compare: Use the planner to explore modes, improving factor provenance, occupancy assumptions, and realistic route data before launching rewards.

Set a fair baseline: Record the traveler’s usual, feasible mode before the trip. Do not automatically compare everyone against flying; use conservative assumptions and flag implausible baselines.

Choose and complete: The traveler independently books and completes a lower-emission option. EcoTrip does not currently provide booking.

Verify with consent: Explore redacted ticket evidence or future transport-partner confirmation. A booking alone may not prove completion. Collect minimal data, specify deletion periods, and avoid default continuous location tracking.

Reward: Award capped EcoCredits only after the required evidence is accepted. Potential campus benefits or transit vouchers would depend on future partner agreements and funding; none are secured.

Reward meaningful choices—not inflated claims

Estimated avoided emissions = max(0, baseline estimate − completed-journey estimate) for the same trip scope.

An illustrative pilot policy could award one EcoCredit per estimated kilogram, rounded down and capped per trip and period. This is a loyalty-policy choice, not a carbon-credit exchange rate. Points would be non-tradable; no cash value, transferability, or redemption is currently available or guaranteed.

The demonstration’s flight comparison must not become a real traveler’s baseline without evidence. Duplicate submissions, invented journeys, and additional travel undertaken to earn points would be excluded. Alternative recognition for people already choosing low-carbon modes would help avoid rewarding only those with previously high emissions.

Keep offsets separate—and reduction first

EcoCredits would not be certified carbon credits. A separate optional offset feature could later connect users with independently verified climate projects, subject to provider due diligence, traceable registry records, and retirement evidence. A point balance, calculator result, or tree-planting promise would not qualify as an offset.

The design would draw on the ICVCM Core Carbon Principles: additionality, robust quantification, independent verification, permanence where relevant, and no double counting. These are evaluation goals, not certification, compliance, or endorsement claims. Offsets would complement reductions—not make a journey automatically carbon-neutral.

Validate the behavior before scaling the promise

The proposed first pilot would recruit 20 consenting student volunteers through an interested campus group. No group or participant is committed. Begin with usability and matched-scenario comprehension before adding rewards or sensitive evidence collection.

Measure comparison completion, understanding of assumptions, feasible mode choices, verified completed trips, repeat participation, and reward cost per verified trip. Keep modeled differences, reported behavior, and verified completion separate; do not extrapolate a small pilot into population-wide avoided-emissions claims.

A potential funding model is a capped campus or employer sustainability budget, not income from issuing uncertified credits. Partnerships, unit economics, redemption obligations, and applicable legal/privacy requirements need review before launch.

EcoTrip makes lower-carbon choices understandable today. EcoCredits would test how to make them worth repeating tomorrow—without confusing ambition with evidence.

Existing project and hackathon-period contributions

Before the hackathon: EcoTrip Planner was an existing project; its GitHub repository was created on 13 January 2026. The sustainable-travel concept and an earlier implementation of the Streamlit interface, emissions components, geographic data, and comparison workflow predated NextStep Hacks. This submission is a continuation, not a claim that the whole project was created from scratch during the event.

During the hackathon period: On 11–12 September 2026, the project underwent review, corrections, testing, and public-app verification. Work included fixes to traveler and return-trip calculations, alternative-savings scope, geographic failure behavior, form/session handling, dependency and deployment configuration, documentation of heuristic assumptions, and hosted map-marker rendering. The revised code was committed to main, and the public app was checked with fresh calculations and map inspection.

After those fixes, still within the submission window: The future EcoCredits and optional offset roadmap was developed for the submission. It remains a proposal; no reward, verification, credit-issuance, redemption, or offset-transaction feature was added to the app.

AI assistance: AI assistance was used for code review, debugging, test work, and submission drafting. The submitted project should attribute actual human/team contributions accurately; the submitter should be able to explain the implementation, tests, and limitations.

Built With

Share this project:

Updates