Routelandia

By:
Jesse Wagner, John Donahue, Josh Proehl, Loc Le, Nasim Sanati, Peter Gicking, Rob Werfelmann

Conceptual

Basic Overview of Routelandia

Android app presents travel times on highways near Portland
Historical data
What do traffic cycles look like?
Lets you know best time to hit highway

OWNER: John Answer these questions: What does your product do? Why is it needed? Who will use it? Routelandia is a native android app that shows travel times along highways. To do this, it pulls historical traffic data from highways around the general Portland area. The hook is this app won't just give you a travel time for just one moment, but before and after it as well. It does this by looking at travel times in the near past to predict them in the future. Traffic tends to follow cycles, as anyone in rush-hour traffic can tell you. Routelandia lets you conveniently see what those cycles look like, letting anyone know when's the best time to hit the road.

Data Into Information

Transportation data collection through Various applications and technologies
- Traffic Detectors
- Data Base Management System
- 3 TB of Traffic Data
Intelligent Transportation Systems & Portal
- A powerful feature of information is performance-based trend representation.
- Collection
- Prediction and diagnostics by statistical inference
- Visualization and analysis on parameters of interest
- Performance trend
- Optimization and evolutionary adaptation of daily performance

OWNER: Nasim - Data is hard! - Information should be easy! ITS is an organization that has a place here at PSU. It stands for "Intelligent Transportation Systems". ITS' role here is to collect and analyze various information about traffic. Portal is a sub-group within ITS that has a more specific role. It stands for Portland, Oregon Regional Transportation Archive Listing. Their goal is to collect and archive various traffic data and statistics in the Portland Metro area. Nasim: A powerful feature of information is performance-based trend representation. Collecting -> diagnostics and statistical inference -> visualization and analysis of parameters -> performance trend -> optimization and evolutionary adaptation to rate of change.

Demo

Development

Who did what?

We split up into teams!

Front end
- Nasim: UI/UX of front-end, visual statistics plot, marker and map interaction, date and time picker, splash screen.
- Loc uses data from the backend draw highway in the map and sets up CI
- John did QA
Back end
- Josh is leader and bearded wizard
- Peter is tall wizard. Wrote PHP and coordinated API structure with front-end
- Jesse is test wizard. Wrote the testing enviornment

OWNER: Rob

So, who did what? I split the teams up into three separate groups initially: Front-end, Back-end and UI design. UI design was a temporary team composed of Nasim and Jesse. They were responsible with coming up with the look of the front-end app. Once that was finished, I re-assigned Nasim to the front-end and Jesse to the back-end.

NEXT FRAGMENT - PRESS DOWN!!!

The front-end was composed of Loc, John and later Nasim. Loc was put in charge of the sub-group and responsible for putting down the groundwork for the application. Nasim implemented several of the graphical features such as the splash screen, date and time picker, and statistics plot. John worked on testing and doing QA work.

NEXT FRAGMENT - PRESS DOWN!!!

The back-end had Josh, Peter and then Jesse. Josh was the lead, bearded Wizard (their choice of title) and laid the foundation for the server application as well as writing the Postgres queries. Peter wrote lots of PHP code and took the lead with working with the Front-end and decided how the API structure would be implemented. When Jesse came on board, because of his experience writing test code at work, he took over the role of writing the entire test suite.

Method and Process

"Full time Student" agile
- No daily stand ups
- Weekly meetings and goal setting
Schedule changes
Handoff process

OWNER: Rob

Each of our schedules varied greatly. John has a full-time work schedule, Nasim is a student at two universities, Jesse has a job and a family. With this situation, we had to adopt a "modified" agile development method. It was not possible to hold daily standups, but we did have weekly meetings where we tracked our progress and set goals for the following week.

Since our last presentation, we've had a few changes to the schedule we laid out for ourselves. For example, we were unable to implement highway chaining, but refined our monthly milestones such as successfully drawing lines over the freeways where there was data and writing queries for route statistics.

Our handoff is pretty simple. Since our software is free, Portal will only need to deploy a build on their servers which the app on the Playstore will reference. No signing over rights or IP is necessary for this project.

Tools Used

Postgres
Java
- Android
- PolyUtil
- AChartEngine
PHP
- Restler
- respect/relational
- behat
Github
- Source Code Management
- Issue Tracking
- Code Reviews

OWNER: JOHN The two primary languages we used were Java, to create the front end, and php to create the back end. The supplied database was written in Postgres, and the back and front end communicate through a REST API with JSON objects. The front end mostly focused on using the supplied Android libraries to create the app, but several other libraries were used as well. The PolyUtil library allowed us to restrict users to only placing markers near our highways, improving the user experience, and AChartEngine (yes,that's it's name) let us elegantly display our statistics. The back end also used some libraries in their programming. Restler allowed us to not just create but automatically document rest endpoints to communicate with the app. We also used respect/relational to manage the different database objects, and it all was tested using behat.

Retrospective

Challenges

Clicking near the line?
Limited only to highway data
- This was a deliberate choice
Currently cannot generate statistics across multiple highways

What we would've done differently

Backend would use different frameworks
- Different language if possible
- The frameworks we used had little support
Setting up a testing environment immediately
Using android hardware instead android emulation
- Android emulation was incredibly slow
- Made programming a very slow and frustrating process
Different strategies for front end communication and issue tracking
- Backend and frontend teams used different management strategies

OWNER: Peter What we would’ve done differently NEXT

First off in the backend, we would’ve wanted to choose different frameowrks The frameworks for PHP we were using didn’t have much support or documentation which made debugging difficult.

Something both the front end and back end didn’t do was setting up a proper testing environment before we started writing code.

Front end initially assumed that android studios native android emulator would be sufficient enough to work on. However the emulator ran incredibly slow on our machines, to the point of making programming an incredibly frustrating process spending lots of time waiting instead of being productive. By the end front end had a couple of old android phones being shared between them which turned out to be better.

Backend had the advantage of having someone with previous technical leadership experience, so we were able to set up a schedule we could all work in from the get-go that kept us on the same page.

If we had more time

IOS App
- Backend would not have to change
- Whole team could work on it
Multi-freeway routing
- Originally planned to be in product
- Became stretch goal after major design change
- Would require pg_routing and design change to Portal database
Error reporting
- Ask the user if our prediction was close
- Serve as a tool to help Portal highlight missing or incorrect data

OWNER: Peter if we had more time NEXT

If we were where we are at now a month ago, we would’ve started working on an iOS app. Most of the team could work on it since the API wouldn’t change, and we could use the lessons we learned from building the android app and apply them.

However before we started the iOS app we’d want to work on multi-highway routing first because this was initially supposed to be in the app but had to be made a stretch goal after we did a major design change in terms of how the app communicated with the server. We discussed a lot of kind’ve hacky ways to go about it but would want to avoid because they relied on PHP doing the number crunching instead of keeping all that heavy computation inside the database. After some research we discovered pg_routing would best tool to suit our needs but it would require some non-trivial design changes in the PORTAL database which would take time than we had to implement.

Finally we wanted to add some kind of error reporting as a tool for us and Portal to highlight missing or incorrect data in the Portal database. This would let us know how far off the mark our predictions were for travel time.

What we learned

Backend Lessons:

How to code in PHP

About model/view controller coding

How to work with behavior driven development testing tools

Frontend Lessons:

How to code an android app

The importance of Google API keys

How to setup a continuous integration service

Group Lessons:

Working on a group coding project for the first time

About rest-ful api construction

How to use GitHub and merge requests and the importance of code reviews

Any Questions?

http://routelandia.github.com