AccessWay

• 

  Where you can contribute

• 

  Landing Page

• 

  Map Filters

• 

  Rate others' contributions

• 

  Map Navigation in Action

Inspiration

During their first week of college, one of our teammates fractured their leg. Buildings they'd walked into without a thought days earlier suddenly became puzzles: which door has a ramp? Is there an elevator? Where? Maps could get them to the building, but not into it. For wheelchair users, people with canes, and parents with strollers everywhere, this becomes a daily struggle. AccessWay makes that as mundane for them as it is for everyone else.

What it does

AccessWay is a navigational tool that allows users to see accessible points such as elevators, ramps, accessible bathrooms, and automatic doors. It features three main components:

• An extensive database of existing accessible features, like stair-free entrances and elevators built on community additions and OpenStreetMap's accessibility database
• A navigation system that displays exact locations of features and how to reach them while also providing the optimal route for avoiding steep hills and stairs
• A community-made and community-verified contribution system that allows anyone to expand the map with image recognition pipelines through OpenAI to recognize junk images & contributions

How we built it

We used FastAPI and Supabase for the backend, using Google OAuth for our user tracking and sign in. We kept our data in four tables, which did map feature storing, user contribution lists, contribution vote tracking, and users and authentication. An OpenAI pipeline tracked new contributions and evaluated whether the images submitted actually depicted their described features. We deployed our backend through Cloudflare Workers on wrangler.

As for our frontend, we used React and Next.js with deployment on Vercel. For the display, we used the Leaflet package to retrieve OSM tilesets and place markers on the map.

Challenges we ran into

There was a consistent problem, where, upon going to an extremely far away destination like Australia, the API would throttle our requests. This required us to cut down on a large chunk of our API calls to prevent rate-limiting, effectively minimizing the amount of back-and-forth we had to do with the OpenStreetMap APIs. As a result, the map is blazingly fast across platforms, noticeably faster than Google Maps in its native app.

Another challenge was Cloudflare's workers system. It had many hidden restrictions, such as a limitation on random numbers during spinup due to predictability, and it required ~50 attempts until all the challenges were successfully diagnosed and resolved. The backend now works well.

Accomplishments that we're proud of

• We shipped a working, live product, now accessible at link, built and deployed all within the hackathon.

• The community verification loop works end to end: A user signs in with Google and submits a photo, name and location. An OpenAI check filters out images that don't show the described feature. The submission then appears on the map as a translucent pin until three other community members approve it, and then it becomes verified.

• The map stays fast at any distance. After OpenStreetMap started rate-limiting our requests for distant destinations, we reworked how we fetch data and greatly cut the number of API calls. The map now stays responsive whether you're on campus or looking at a city on the other side of the world.

• We got Python running on Cloudflare's edge. It took around 50 deploy attempts to find and work around Workers' hidden restrictions, but the backend is now stable.

• It's something we'd use. The idea started with a teammate who had to find their way around campus on a fractured leg. We built the tool they wish they'd had, for people who face the same barriers every day.

What we learned

• Sometimes, things are too good to be true. Serverless platforms are not all they claim to be. Running Python on Cloudflare Workers meant learning, through about 50 deploys, that the startup environment has limits you won't see locally, such as blocking random number generation at startup. Next time we'd deploy early and often instead of saving it for the end.

• Building from lived experience helped. Having a teammate who had actually struggled to get into buildings meant we could check our ideas against a real person's needs and frustrations instead of guessing.

• Crowdsourced data needs to be trustworthy from the start. An open map invites spam and mistakes, so we built in two layers of checks: an AI filter that catches mismatched photos, and a three-person community vote. Showing unverified pins as translucent lets our users decide how much to rely on them.

• Accessibility happens at the level of individual doors. Most maps treat a building as either accessible or not. In reality, one building can have a stepped main entrance, a ramp around the side and an elevator that's hard to find. By designing for specific entrances, not whole places, we structured our data in the way it was needed.

What's next for AccessWay

The main next steps are:

• Feed the community data we receive back into OpenStreetMap for the benefit of multiple maps
• Work with campus disability offices to organize contribution drives for the sake of disabled university students
• Track individual contributor reputations and add a "Report as Outdated" button
• Map every entrance on GT campus

Built With

• cloudflare
• fastapi
• next.js
• python
• react
• supabase
• vercel