StreetHazards

Inspiration

When my mom was driving one day after coming back from a resturant, she hit a pothole that we have never learned of. I had a drink in my hand, and it spilled all over me, which made everyone angry and sad. Our goal was to make an app to prevent this from happening to even more people, so that made the idea of our app, StreetHazards.

What it does

It warns people where dangerous and hazardous places which people post onto a map and you can view the map

How we built it

We built the website using HTML5, CSS3 for the Interface, and JS for the functionality. We also used Leaflet, OpenStreetMap, and Nominatim for the Searching of locations and the interactive map. Firebase was used to host our website, and Firestore was used to store the Hazard data.

Challenges we ran into

written by Jayden Maps merging. Three people. One repo. Two maps. Two members independently built versions of the community map. When we merged them, we ended up with two maps, two scripts, and two stylesheets competing for the same page. The map would behave differently depending on whose code ran first, and parts of the application were overwriting each other. We rebuilt the structure around one map module and clear communication. The biggest lesson wasn't about Git. We needed to communicate as a team before writing code. We ran into problems like “It works on my machine.”. But firebase configuration, working from different branches, uncommitted changes, and deploying it too late already gave us so much to worry about. We learned to differentiate between whether code works locally or whether the app was already updated. A major part of debugging became figuring out whether the problem was actually the code, Git, or deployment. Hazard Hunt A timed game where players scan a city scene, identify hidden hazards, and learn why they're dangerous. It was simple: 19 hazards. 3 minutes. The goal is to train yourself to look at an ordinary environment differently. A cracked sidewalk, pothole, or another small detail can become a serious problem when overlooked. Because the real world doesn’t have a “Start Game” Button. The concept was exciting, but there was one problem: we weren’t clearly communicating about it. There was no clear communication regarding the game’s progress, it’s place in the entire project, or if everyone felt comfortable being included. The teammate working on HazardHunt felt onboard, while the rest of the teammates had a different understanding of where the project was going. Eventually, HazardHunt began overriding parts of the Community Map(finishing the hunt in order to access the Community Map) and created merge conflicts with teammates. It felt that the project was going in two complete directions. For a moment, it felt as if the team split in half because of the misconception. The problem wasn’t really the game itself. The problem was that we never agreed to what the project was supposed to be. We agreed to compromise: the main StreetHazards web page would focus entirely on the community map, giving users a clear experience for reporting, discovering, and verifying real-world hazards. HazardHunt would be separated from the main project and could become its own personal project. That decision gave the team a clear direction again. More importantly, it taught us something that had nothing to do with JavaScript, Firebase, or maps: Communication is part of the development. A project can have clean code and a good idea, but if everyone is building toward a different vision, the codebase will eventually show it. Through this experience, we learned to communicate major changes before implementing them, make large decisions together, and establish a single direction for a project.

Accomplishments that we're proud of

Jayden A fully functional community reporting system StreetHazards isn't only a map with pins. Users can create reports, add information, discover nearby hazards, vote on resolved hazards, and participate in the community leaderboard. Real-time updating Hazards and votes sync through Firestore, allowing users to see changes without refreshing. Community verification Reports don’t get removed after one vote because the resolution system requires agreement from multiple people. No unnecessary account People can explore the map without immediately being forced to create an account, while authentication is available for features that need a user identity. Location-aware Users can find hazards around them and sort nearby reports by distance. We documented the architecture, code structure, and technical decisions so we can explain how the system works instead of just showing the finished interface.

What we learned

We didn't know how to use Firebase but we learned to use it. We also learned of some cool API's that could show the map and locations with. We also needed to calculate the distance between 2 points on a sphere so we learned the Haversine formula

What's next for StreetHazards

There is a problem with our app: people can spam or create false hazards. Currently, our app is running on the honor system, but later on, we want to incorporate features like Admin Moderation or a antispam bot.

Built With

• css3
• firebase
• firestore
• html
• html5
• javascript
• leaflet.js
• nominatim
• openstreetmap