BobTheBuilders - Restaurant Finder

Sign-up/Login Page
Map/List View of Places Filter Search & Recommendation
User Profile Page to reset Password and Saved Places
Admin Page to CRUD Users and their priviledge levels
System Architecture Diagram

Inspiration

Quandoo Website link

Our Product

Restaurant Finder link

What it does

Search for places to eat, based on filters.

Location Detection The app requests the user's location using the coordinates to find nearby restaurants Data Fetching

Queries the overpass API for restaurants/cafes in the area
Processes and caches the results Search and Recommendations Converts user queries and fetched restaurant data into embeddings using ‘all-mpnet-base-v2’ model Compares query embeddings with restaurant/cafes embedding through cosine similarity Return top restaurant base on cosine similarity scores and displays them on a interactive map Filtering Users can further filter restaurants/cafes (price,rating,wheelchair accessibility,etc.)

How we built it

We took out the booking aspect, focused on the location-based recommendation algorithm for places to eat as our value-add.

Access Level Definitions Guest: Can view the map, search, and use filters. Cannot view/save/remove saved restaurants. Cannot access profile or admin dashboard. User: All guest features. Can view/save/remove saved restaurants. Can access profile. Admin: All user features. Can access the admin dashboard.

Challenges we ran into

Google Places API is required a credit card on file even for the free tier, none of us wanted to risk a charge, so we decided to go with the public OpenStreet based Overpass API but its restaurant data was limited. Also things were not moving as they should on the page and having all of us working remotely is not optimal for creating a product on such a short timeline.

Another key challenge we encountered was developing an effective recommendation algorithm. Our initial approach involved using a TF-IDF vectorizer on the restaurant data and then calculating the cosine similarity between this data and the user's query. However, TF-IDF primarily measures the frequency of words within documents and across a corpus, focusing on exact word matches. As a result, the algorithm only considered overlapping words between the user's query and the restaurant descriptions. This limitation meant that if a user's query contained words that were semantically similar but not identical to those in the restaurant data, the algorithm would fail to recognize the connection.

To address this, we shifted our strategy towards a more robust, semantic-based approach. We adopted a sentence transformer model—specifically, the all-mpnet-base-v2 model from Hugging Face—which is designed to encode sentences and short paragraphs into dense vector representations. Unlike TF-IDF, this model captures the semantic meaning of text, allowing words and phrases with similar meanings to be mapped to nearby points in the vector space. This significantly improved our algorithm's ability to match user queries with relevant restaurants, even when there were no direct word overlaps, resulting in more accurate and meaningful recommendations.