github repo badge: frontend github repo badge: frontend github repo badge: backend github repo badge: backend

SBU Bathroom Finder

Welcome to SBU Bathroom Finder, your go-to WebApp for locating the nearest and best bathrooms on Stony Brook University's campus! Tailor your restroom search based on gender, accessibility, ratings, and amenities. While currently designed for SBU, our open-source approach invites community members from other universities to contribute and create maps for their campuses using our built-in map creator. Explore and find the perfect bathroom with ease! This project was made for Hopper Hacks 2024 and we hope you enjoy our project!

Inspiration

As residents of NYC, we've all faced the challenge of locating clean and accessible bathrooms in a bustling city. Recognizing the widespread nature of this issue, we decided to tackle it on a smaller scale starting with the the University, we all know and love, SBU! Our collective knowledge about the campus bathrooms serves as a proof of concept, inviting others to contribute and adapt the solution to their own university environments.

Additionally, our shared experience with the Computational Geometry class here at SBU has made us excited to try our hand at implementing what we've learned in class.

What it Does

Using A* and Point Sampling algorithms, the SBU Bathroom Finder enables users to locate the nearest restroom by generating a color-coded grid. On the Gallery and Viewer pages, users encounter a grid displaying a Voronoi diagram, where bathrooms serve as hotspots, each denoted by a unique color to signify proximity. Meanwhile, walls are delineated in black.

After either logging in or signing up, users unlock even more features. For example, they gain the ability to scroll on Google Maps, insert their own grid, and mark all walls and bathrooms. Then, users can press a "compute geometry" button to generate a Voronoi diagram for an entirely new page. Users can also rate existing restrooms on Stony Brook's campus based on accessibility, cleanliness, and other features. Finally, they can log out when they're finished using the application.

How we Built it

Backend

Deciding our implementation and what exactly we wanted to achieve was pretty tough. We floated around multiple ideas but eventually settled on creating a Voronoi diagram of some sorts. Thus, our extensive research began on implementations of Voronoi diagrams that had already been accomplished.

The problem was though, that the Voronoi diagram implementations we found in Golang did not account for walls, which was problematic given that we couldn't just have people phase through the walls and so we started trying to implement our own.

This first led us to the Jump Flooding Algorithm and we watched this excellent youtube video explaining the concept, but while this algorithm was cool to learn about, it was out of the scope of this project to create a customized Jump Flooding Algorithm that would account for obstacles.

We settled on implementing the Voronoi diagram in an unconventional but more naive approach, taking advantage of A* pathfinding, Distance Hueristics, and some clever splitting of our input into tiles represented by a 2D array.

With the A* pathfinding algorithm we had to implement our own version as many Golang implementations wanted to take in a string representation which would not be compatible with creating Voronoi diagrams.

Overall, we did end up overcoming most of the challenges we faced in our Backend, though this doesn't mean it's perfect and further optimizations/changes will be mentioned in future sections. So, for now, let's move onto the Frontend challenges.

Frontend

For the frontend of the SBU Bathroom Finder, we utilized Svelte as our primary framework. Svelte is a modern JavaScript framework that focuses on performance and simplicity. We were able to build a reactive user interactive as a result, with various pages enabling the user to login, sign up, view a gallery, edit, and log out. Users are also able to complete forms and interact with images and grids. Grids are fully interactive, with users being able to mark both walls and restrooms.

To make the map interactions fully possible, we also used the Google Maps API. This allows the Voronoi diagrams created by the backend to be displayed as a grid over a map of Stony Brook's campus. Users are also able to scroll through Google Maps in order to pick a location for a new bathroom grid.

TypeScript was used to store user information from signing up, logging in and completing forms.

Challenges we ran into

SBU Bathroom Finder was an interesting and tall project for us to tackle as we didn't have much experience in Golang or Svelte and we had never done any pathfinding or projects that required complex distance calculations before. Doing this in 24 hours didn't make it much easier. Implementing our own versions of the A* and Point Sampling algorithm was quite difficult as we had no experience coding these before, but eventually we got an approximation of the Voronoi diagram which is pretty close to what we wanted.

Accomplishments that we're proud of

Our team is proud that we made finding bathrooms more accessible at Stony Brook University. We are also happy we got to implement what we learned in our Computational Geometry class in a software project.

What we learned

No one on our team had experience with Svelte before, so we all familiarized oursevles with a new JavaScript framework. We also all used the Google Maps API for the first time during this project, so we learned how to integrate this google both into a Svelte frontend and our Golang backend. We also learned how to implement an A* star and point sampling algorithms into our backend.

What's next for SBU Bathroom Finder

We want to implement a more largescale bathroom finder, that is easily adaptable to metropolitan and campus areas. We also want to improve user functionality by having an improved rating experience that is better integrated with our main Gallery and Viewer.

If we had more time, we would have written a Jump Flooding Algorithm with the following customizations, based on a few stack overflow posts (notably this one):

  • if the tile is colored with the boundary color, discard consideration for recoloring automatically
  • implement A* for the dist() check which respects the walls

Built With

Share this project:

Updates