-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathindex.html
626 lines (531 loc) · 26.8 KB
/
index.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
<!doctype html>
<html lang="en">
<head>
<meta charset="utf-8">
<title>Routelandia - Final Presentation</title>
<meta name="description" content="Final Presentation for the Routelandia project">
<meta name="author" content="PSU Capstone 2014 Team B">
<meta name="apple-mobile-web-app-capable" content="yes" />
<meta name="apple-mobile-web-app-status-bar-style" content="black-translucent" />
<meta name="viewport" content="width=device-width, initial-scale=1.0, maximum-scale=1.0, user-scalable=no">
<link rel="stylesheet" href="css/reveal.min.css">
<link rel="stylesheet" href="css/theme/default.css" id="theme">
<!-- For syntax highlighting -->
<link rel="stylesheet" href="lib/css/zenburn.css">
<!-- If the query includes 'print-pdf', include the PDF print sheet -->
<script>
if( window.location.search.match( /print-pdf/gi ) ) {
var link = document.createElement( 'link' );
link.rel = 'stylesheet';
link.type = 'text/css';
link.href = 'css/print/pdf.css';
document.getElementsByTagName( 'head' )[0].appendChild( link );
}
</script>
<!--[if lt IE 9]>
<script src="lib/js/html5shiv.js"></script>
<![endif]-->
<style type="text/css">
html.img-left div.slide-background.present {
background-position: left;
margin-left:10px;
}
</style>
</head>
<body>
<div class="reveal">
<!-- Any section element inside of this container is displayed as a slide -->
<div class="slides">
<section>
<h1>Routelandia</h1>
<br />
<br />
<p>By:<br/>Jesse Wagner, John Donahue, Josh Proehl, Loc Le, Nasim Sanati, Peter Gicking, Rob Werfelmann</p>
<aside class="notes">
OWNER: Rob
<p>Thanks for coming everyone! My name is Rob, I'm the
team lead for Team B. With me tonight I have 6 developers: ---HAVE TEAM
INTRODUCE THEIR NAMES--- Tonight we'd like to proudly show you
the product we've all been hard at work on for the last 5
months: Routelandia.</p>
</aside>
</section>
<section>
<section>
<h2>Conceptual</h2>
</section>
<section>
<h2>Basic Overview of Routelandia</h2>
<p>
<ul>
<li>Android app presents travel times on highways near Portland</li>
<li>Historical data</li>
<li>What do traffic cycles look like?</li>
<li>Lets you know best time to hit highway</li>
</ul>
</p>
<aside class="notes">
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.
</aside>
</section>
<section>
<h2>Data Into Information</h2>
<ul>
<li class="fragment">
<b>Transportation data collection through Various applications and technologies</b><br />
<ul align="left">
<li>Traffic Detectors</li>
<li>Data Base Management System</li>
<li>3 TB of Traffic Data</li>
</ul>
</li>
<li class="fragment">
<b>Intelligent Transportation Systems & Portal</b><br />
<ul align="left">
<li>A powerful feature of information is performance-based trend representation.</li>
<li>Collection</li>
<li>Prediction and diagnostics by statistical inference</li>
<li>Visualization and analysis on parameters of interest</li>
<li>Performance trend</li>
<li>Optimization and evolutionary adaptation of daily performance</li>
</ul>
</li>
</ul>
<aside class="notes">
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.
</aside>
</section>
<section data-transition="concave">
<img src="img/architecture_diagram.png" id="architecture_diagram" height="675" />
<aside class="notes">
OWNER: Loc
The top part is the portal main database. Data is read only. It’s Postgres with PostGIS Plugin
The green box is the server .Its written by PHP language bases REST API with Restler framework.
the server deployed through portal
The blue box is the client. The android app will talk to the server via Rest API and interchange the JSON data.
It draw the highway segment data onto the map layout which provided by google mapAPI
The app will publish through google play store
</aside>
</section>
</section>
<section data-background="#666666" data-background-transition="zoom">
<section>
<h2 style="color:white;">Demo</h2>
</section>
<!--
Other images to use?
create mode 100644 img/barGraph.png
create mode 100644 img/errorMessage.png
create mode 100644 img/spinWheel.png
-->
<section>
<img src="img/loading_screen.png" height="675" />
<aside class="notes">
OWNER: Josh<br />
<br />
The app starts with the loading screen, and begins loading highway data in the background.
</aside>
</section>
<section>
<img src="img/mapNoMarkers.png" height="675" />
<aside class="notes">
OWNER: Josh<br />
<br />
Once the highway data is loaded we display all of the highways that we have data for, drawing each as a unique color
so that the user can pick two points along the same highway.
</aside>
</section>
<section>
<img src="img/mapWithMarkers.png" height="675" />
<aside class="notes">
OWNER: Josh<br />
<br />
The application enforces that the user taps a point within 200 meters of a highway, so that we can determine where
along the highway they want to start and end their journey.
</aside>
</section>
<section>
<img src="img/timePicker.png" height="675" />
<aside class="notes">
OWNER: Josh<br />
<br />
The user then picks the time they're interested in traveling, and which day of the week.<br />
Day of the week important, because the statistics we're about to see are generated for the last 6 weeks of the chosen
weekday. This allows the user to determine if traffic on a Friday is different than traffic on a Tuesday.
</aside>
</section>
<section>
<img src="img/barGraphBigger.png" height="675" />
<aside class="notes">
OWNER: Josh<br />
<br />
This shows the 4-hour block (2 hours to either side) of the user's chose time, broken up into 15 minute increments,
letting the user see what the average travel time for their route, and average speed across their route is, during
each 15 minute interval.<br />
At the top you'll see a percentage accuracy measurement, which gives the user some sort of idea about how much to trust these numbers.
</aside>
</section>
<section>
<img src="img/statsTable.png" />
<aside class="notes">
OWNER: Josh<br />
<br />
If you rotate your phone sideways you'll see that we give the same information in a table, which includes the accuracy
measurement for each 15 minute interval. Accuracy is the number of readings that the detectors in the chose route *should* have given
off over a 15 minute interval, vs how many we actually got when we did the query.<br />
This may not be as interesting to the end user, but to Portal/ODOT this information is interesting to know as it allows you to see trends in where detectors are firing every 20 seconds or not.
</aside>
</section>
</section>
<section data-background="#dddddd" data-background-transition="zoom" data-transition="zoom">
<section><h2>Development</h2></section>
<section>
<h2>Who did what?</h2>
<p>
We split up into teams!
<ul>
<li class="fragment"><b>Front end</b>
<ul>
<li>Nasim: UI/UX of front-end, visual statistics plot, marker and map interaction, date and time picker, splash screen.</li>
<li>Loc uses data from the backend draw highway in the map and sets up CI</li>
<li>John did QA</li>
</ul>
</li>
<li class="fragment"><b>Back end</b>
<ul>
<li>Josh is leader and bearded wizard</li>
<li>Peter is tall wizard. Wrote PHP and coordinated API structure with front-end</li>
<li>Jesse is test wizard. Wrote the testing enviornment</li>
</ul>
</li>
</ul>
</p>
<aside class="notes">
OWNER: Rob
<p>
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.
</p>
<p>NEXT FRAGMENT - PRESS DOWN!!!</p>
<p>
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.
</p>
<p>NEXT FRAGMENT - PRESS DOWN!!!</p>
<p>
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.
</p>
</aside>
</section>
<section>
<!-- <h2>Schedules and Process</h2> -->
<h2>Method and Process</h2>
<ul>
<li>"Full time Student" agile
<ul>
<li>No daily stand ups</li>
<li>Weekly meetings and goal setting</li>
</ul>
</li>
<li>Schedule changes</li>
<li>Handoff process</li>
</ul>
<aside class="notes">
OWNER: Rob
<p>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.</p>
<p>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.</p>
<p>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.</p>
</aside>
</section>
<section>
<!-- TODO: Align the bullet points to the left instead of centered -->
<h2>Tools Used</h2>
<p>
<ul>
<li>Postgres</li>
<li>Java
<ul>
<li>Android</li>
<li>PolyUtil</li>
<li>AChartEngine</li>
</ul>
</li>
<li>PHP
<ul>
<li>Restler</li>
<li>respect/relational</li>
<li>behat</li>
</ul>
</li>
<li>Github
<ul>
<li>Source Code Management</li>
<li>Issue Tracking</li>
<li>Code Reviews</li>
</ul>
</li>
</ul>
</p>
<aside class="notes">
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.
</aside>
</section>
</section>
<section data-background="#dddddd" data-background-transition="convex" data-transition="convex">
<section>
<h2>Retrospective</h2>
</section>
<section>
<h2>Challenges</h2>
<ul>
<li>Clicking near the line?</li>
<li>Limited only to highway data
<ul>
<li>This was a deliberate choice</li>
</ul>
</li>
<li>Currently cannot generate statistics across multiple highways</li>
</ul>
<aside class="notes">
OWNER: Josh<br />
<br />
We chose to use highways only because of the differences in the data structure for the arterials...<br />
Clicking near the line was hard, Android doesn't seem to like objects on it's maps...<br />
Multiple highways. Multi-path routing, different data types on arterials, missing sections, all hard problems!
</aside>
</section>
<section>
<h2>What we would've done differently</h2>
<p>
<ul>
<li class="fragment">Backend would use different frameworks
<ul>
<li>Different language if possible</li>
<li>The frameworks we used had little support</li>
</ul>
</li>
<li class="fragment">Setting up a testing environment immediately</li>
<li class="fragment">Using android hardware instead android emulation
<ul><li>Android emulation was incredibly slow</li>
<li>Made programming a very slow and frustrating process</li></ul>
</li>
<li class="fragment">Different strategies for front end communication and issue tracking
<ul><li>Backend and frontend teams used different management strategies</li></ul>
</li>
</ul>
</p>
<aside class="notes">
OWNER: Peter
What we would’ve done differently
NEXT <br />
<p>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.
</p>
NEXT <br />
<p>Something both the front end and back end didn’t do was setting up a proper testing environment
before we started writing code. </p>
NEXT
<br />
<p>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.</p>
NEXT
<br />
<p>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. </p>
</aside>
</section>
<section>
<h2>If we had more time</h2>
<p>
<ul>
<li class="fragment">IOS App
<ul><li>Backend would not have to change</li>
<li>Whole team could work on it</li></ul>
<li class="fragment">Multi-freeway routing
<ul><li>Originally planned to be in product
<li>Became stretch goal after major design change</li>
<li>Would require pg_routing and design change to Portal database</li></ul>
</li>
<li class="fragment">Error reporting
<ul><li>Ask the user if our prediction was close</li>
<li>Serve as a tool to help Portal highlight missing or incorrect data</li></ul>
</li>
</ul>
</p>
<aside class="notes">
OWNER: Peter
if we had more time
NEXT
<br />
<p>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. </p>
NEXT
<br />
<p>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. </p>
NEXT
<br />
<p>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. </p>
</aside>
</section>
<section>
<h2>What we learned</h2>
<p>
<ul>
<li>Backend Lessons:</li>
<ul><li>How to code in PHP</li></ul>
<ul><li>About model/view controller coding</li></ul>
<ul><li>How to work with behavior driven development testing tools</li></ul>
<li>Frontend Lessons:</li>
<ul><li>How to code an android app</li></ul>
<ul><li>The importance of Google API keys</li></ul>
<ul><li>How to setup a continuous integration service</li></ul>
<li>Group Lessons:</li>
<ul><li>Working on a group coding project for the first time</li></ul>
<ul><li>About rest-ful api construction</li></ul>
<ul><li>How to use GitHub and merge requests and the importance of code reviews</li></ul>
</ul>
</p>
<aside class="notes">
OWNER: Jesse
For most of us, this was the first time we had worked on a group coding project. we had some issues with communication between
different team members and teams but we worked hard at it and things got better. many of us had never coded for an android app
or setup a web server before and now we have gained skills we can hopefully use after school. This has been a rewarding
experience for all of us and we hope our project is useful. Thank you
</aside>
</section>
</section>
<section data-background="#dddddd" data-background-transition="concave" data-transition="concave">
<h2>Any Questions?</h2>
<br />
<br />
<br />
<br />
<div>
<img src="img/google-play-icon.png" style="border-style:none;" /><br />
<img src="img/Octocat.png" width="100" style="border-style:none;" /><br />
http://routelandia.github.com
</div>
<aside class="notes">
OWNER: JESSE
</aside>
</section>
</div>
</div>
<script src="lib/js/head.min.js"></script>
<script src="js/reveal.min.js"></script>
<script>
// Full list of configuration options available here:
// https://github.com/hakimel/reveal.js#configuration
Reveal.initialize({
controls: true,
progress: true,
history: true,
center: true,
theme: Reveal.getQueryHash().theme || 'serif', // available themes are in /css/theme
transition: Reveal.getQueryHash().transition || 'default', // default/cube/page/concave/zoom/linear/fade/none
// Parallax scrolling
// parallaxBackgroundImage: 'https://s3.amazonaws.com/hakim-static/reveal-js/reveal-parallax-1.jpg',
// parallaxBackgroundSize: '2100px 900px',
/* IF we're going to use this we'll need to update the server to match...
multiplex: {
secret: null, // null so the clients do not have control of the master presentation
id: '00f1450e038648f0',
url: 'capstoneaa.cs.pdx.edu:1948'
},
*/
// Optional libraries used to extend on reveal.js
dependencies: [
{ src: 'lib/js/classList.js', condition: function() { return !document.body.classList; } },
{ src: 'plugin/markdown/marked.js', condition: function() { return !!document.querySelector( '[data-markdown]' ); } },
{ src: 'plugin/markdown/markdown.js', condition: function() { return !!document.querySelector( '[data-markdown]' ); } },
{ src: 'plugin/highlight/highlight.js', async: true, callback: function() { hljs.initHighlightingOnLoad(); } },
{ src: 'plugin/zoom-js/zoom.js', async: true, condition: function() { return !!document.body.classList; } },
{ src: 'plugin/notes/notes.js', async: true, condition: function() { return !!document.body.classList; } },
{ src: '//cdnjs.cloudflare.com/ajax/libs/socket.io/0.9.10/socket.io.min.js', async: true },
{ src: 'plugin/multiplex/client.js', async: true }
]
});
</script>
</body>
</html>