EmoRoute Tokyo

A privacy-first Tokyo pilgrimage route planner that compares the fastest route with an emotion-aware route using synthetic mood data.

Comment

Inspiration

The fastest route is not always the most meaningful one. When visiting places connected by a personal theme or emotional interest, travelers may care about atmosphere and emotional resonance as much as travel time.

EmoRoute Tokyo was inspired by my previous research on sentiment-enhanced recommendation systems for anime pilgrimage tourism. I wanted to turn that idea into a small, transparent, and privacy-conscious application.

What it does

EmoRoute Tokyo compares two walking routes:

  • Fastest maximizes the number of feasible places and then minimizes walking distance.
  • Emotion also maximizes the number of feasible places, but favors places with stronger synthetic mood utility when the place count is the same.

Users select a starting station, available time, preferred mood, and walking tolerance. The application then displays both routes on an interactive map, together with distance, walking time, total time, visited places, and mood fit.

The current demo contains five approved stations and eight approved places in Tokyo. All mood and popularity scores are synthetic. No private research data or personal profiles are included.

How I built it

I built the application with Python, Flask, JavaScript, HTML, CSS, and OpenStreetMap.

The planner is deterministic and uses precomputed street-level walking geometry. Blue represents the Fastest route, while coral represents the Emotion route. Users can hide either route to compare them more clearly.

I used GPT-5.6 through OpenAI Codex as my development partner. Codex helped me:

  • Define privacy and data boundaries
  • Build and test the route-planning logic
  • Identify and correct scoring bias
  • Review coordinates and walking routes
  • Develop the bilingual Flask interface
  • Prepare documentation and deployment

I reviewed and approved every phase of the project.

The deployed application does not call GPT-5.6 or the OpenAI API at runtime, and users' planning choices are not sent to OpenAI. An offline mode is also provided, making zero external requests and displaying an offline route diagram.

Challenges I ran into

One major challenge was making the comparison between the two routes fair. Both routes needed to maximize the number of feasible places before applying their different optimization goals. Otherwise, the Emotion route could appear better simply because it visited fewer places.

Another challenge was protecting privacy while adapting ideas from my earlier research. I solved this by excluding private research data and personal profiles and replacing them with a small, clearly documented synthetic dataset.

I also reviewed map coordinates, route geometry, time calculations, and scoring results to make the demo deterministic and reproducible.

Accomplishments that I am proud of

  • Created a working comparison between time-efficient and emotion-aware routes
  • Built a transparent deterministic planner with reproducible results
  • Used only approved locations and synthetic mood data
  • Added bilingual English and Japanese support
  • Added an offline mode with zero external requests
  • Deployed a complete public demo with documentation and tests

What I learned

I learned that AI-assisted development is most effective when the human developer defines clear boundaries, verifies outputs, and makes the final decisions.

I also learned that route optimization is not only about finding the shortest path. A useful route can balance feasibility, walking effort, time, and the kind of experience the user wants.

What's next for EmoRoute Tokyo

Next, I would like to add more user-approved locations, improve accessibility information, and explore locally computed preference controls. I would also like to conduct user testing while keeping the synthetic-data and privacy-first design.

Built With

Share this project:

Updates