Applying commercial routing techniques to solve common consumer problems.
A user can join any existing meetup, or create a new one.
Once joining a meetup, a map displays the location of each user in the meetup.
See the working app here: https://least-cost-meetup.firebaseapp.com
See our slide presentation here: https://slides.com/mikewilburn/corral
We have had numerous experiences where we wanted to meet up with friends in various group chats. It can sometimes be a laborious process finding out a centrally-located spot that meets our requirements and objectively considers the travel times of each participant. This idea spun from that.
What it does
Participants can provide their current or manual location and give meeting spot criteria (i.e. restaurant, coffee shop, pizza parlor, etc.) which filters a point of interest feature layer. A geoprocessing service identifies the times for participants to travel to each destination that meets the point of interest criteria, then presents these options in a list ordered by the least summed travel time for all participants.
The app is exposed in the form of a web app which can be visited via a URL. The user begins by either A) setting up a new meetup, or B) choosing to join an existing meetup. A "meetup" is comprised of the following: 1) a name, 2) a place type (to filter the POI layer), and 3) a list of users who are users to that meetup.
Once a meetup is set up and entered, a map displays the locations of all users for that meetup as well as a single -returned POI feature whose travel time would allow everyone in the meetup to reach that destination in the least time possible.
How we built it
- React: JS library for building user interfaces
- Google Firebase: Firestore realtime database and Google authentication
- Navigator for ArcGIS: pre-installed Android/iOS app opens to handle navigation request by feeding URL scheme from web app
Challenges we ran into
- Considered using Tracker for ArcGIS (in beta) to capture each user's location, but found the implementation too cumbersome given the time constraints.
- Tyler learning the JS API. A Java desktop app (Windows/macOS/Linux) didn't make sense for this scenario.
- Sourcing and configuring MMPK for Navigator
- Had to restart server hosting the POI layer (feature service) and geoprocessing service (which generates the origin-pair matrix)
- Mike hasn't used Adobe Illustrator since college (had a very rough go at making the app logo)
Accomplishments that we're proud of
- Working as part of only a 3-person team!
- Using minimal time over the weekend to develop a complete app (ish)
What we learned
- It's always good to focus on a minimum shippable product first, then add in the luxuries later. In a scenario such as this, there's likely not going to be time for those nice-to-haves!
What's next for Corral
- Expose mode of travel as an input for users to choose. This would be used as another variable for summing travel times (i.e. User A biking, User B walking, and User C taking public transit).
- Expose button for on-demand route request, as opposed to triggered whenever a user's location is updated.
- Separate options for rooms to be either private or public, with private meetups accessed via a magic link
- Polish UI layouts to handle a greater variety of mobile devices (dimensions and DPIs)