-
Notifications
You must be signed in to change notification settings - Fork 2
/
ideas
223 lines (156 loc) · 8.71 KB
/
ideas
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
Filtering
=========
With refactoring to store information about trips explicitly, we can
extend filter functions to allow filtering by:
- origin/destination latlng
- starting time, ending time (e.g. get trips from 4 a.m. to noon
over several days)
- starting/ending cleanliness
- starting/ending fuel level
- possibly others that prove interesting
Graphing
========
Finish up refactor
------------------
The graphing functions have largely been cleaned up as result of changing
how locations/trips are provided. There is a bit remaining, noted with TODOs,
particularly involving matplotlib figure and axes setup. The whole matplotlib
setup is hacky and might be worth replacing with straight-up bitmap use.
Map subsets
-----------
Limit the generated map area to a given set of boundaries to essentially
zoom in or focus on an area. I've done this manually for a blog post but
it would be good to have it done automatically. Requires being able to
generate maps from OSM source (described in "Mapping section").
Visualization of accessibility/density
--------------------------------------
There is much that can be done in analysis.graph.make_accessibility_background.
Extend the function to support gradual transparency and/or colour heatmap
based on distance from nearest vehicle. Gradual transparency was not done
due to performance problems but perhaps it can be improved. Could try to
use matplotlib's hexbin or something.
Causes of carshare use: population/business density, etc
--------------------------------------------------------
Does higher population density in home areas drive higher carshare use, when
compared between cities? When compared within cities?
Could also do something fancy like colour-analyze sat images, for instance
in Vancouver low-density residential areas are much greener because of trees,
while business and higher-density residential tends to be greyer. So this could
work around having to find numerical density data and be a cool experiment.
Further ideas
-------------
Maybe add street grid angle to city information, if specified, change
accessibility mask shape to take this into account. For example, instead of
using one circle, we could overlay two ellipses aligned with
the street grid to get a closer approximation of walking distance.
This will of course be useless for cities without a strong grid, but
most of Vancouver, Toronto, Seattle could benefit.
Perhaps highlight vehicles that have just moved into an area fairly lacking
in cars. This would support an algorithm to calculate possible discount
for moving vehicles in off-peak direction (until sign-off, it'll be
estimated discount only, since we don't know if 10 other people are driving
there), disguised as a map for time being. Dynamically price all the things.
Mapping
=======
Automatically generate maps of a given area given OSM export. This would
free me up from depending on hacky OSM website exports and allow me to
customize what is included (no lesser roads, no city borders, etc).
Need to research on existing OSM renderers I could reuse.
Analysis angles
===============
Based on start/end positions
----------------------------
Transit competitiveness: get start&end lat long, trip time, run the start&end
through transit journey planner and compare durations.
Origin/destinations: where do cars leaving Vancouver's West End head to?
Where do cars arriving in Seattle's South Lake Union come from? Particularly
useful if combined with time analysis to show inbound/outbound commutes and
the like.
In grid-based cities, how close do cars park to the grid arterials? That is,
is more usage nearer to grid, or inside the blocks, where the transit is
farther away?
Carshare availability analysis: given a position, map nearby fixed carshare
stations and historical availability, and calculate/map historical availability
of floating carshare vehicles nearby. Big project but pretty interesting.
Might need to get data from Zipcar/Modo/Communauto/etc for full effect.
New kind of visualization: show cars as they're moving, with a trail behind
them for, say, 30 minutes, then disappear it. Can show trips as they're
happening throughout the day. Easier to do now with the new structure.
Also, for cities with multiple systems, it might be pretty fun to map
multiple systems in one video. Even more moving cars, and potential differences
between the usage of the different systems!
Based on time
-------------
Isolate by time: show trips, start/end points. split at 4 am / noon / 8 pm,
show commutes. Maybe do a sub-graph for only 2 am to 6 am to show night
activity that might be replacing inadequate nighttime transit?
Get ratio/percentage of cars that enter/exit an area with given boundaries
during given timeframe, e.g.: between 9 am and 3 pm, how many cars are
there in downtown Seattle or Calgary, how many arrive, how many leave?
Show when a destination is popular (day/week), or which destinations
are strongly popular to enter / leave at given time.
For cities with a central downtown, calculate radial distance from downtown
for start and end of trip, average and collect over 24 hours, graph.
This might be an easy way of showing most trips starting in the suburbs and
and ending downtown in the morning rush, and starting downtown and ending
in the suburbs in the evening rush. Play around, see what comes up.
- suggested in https://www.reddit.com/r/Austin/comments/208ivi/#cg0t0l0
Collect idle times between trips.
I suspect heavily binomial distribution - most are grabbed right away or
wait a long time - or might show up as a fat, long tail.
Calculate and show idle times by times of day. 11 pm - 7 am, 7 am - 6 pm,
6 pm - 11 pm, or something. Check every hour to find the transition points.
For cars that hadn't moved for a while, find day of week/time of first trip.
If it's during work hours, particularly on a specific day, it might indicate
an administrative move rather than a customer trip - and analysing a subset
of only administrative moves would be pretty interesting.
Based on reported fuel level
----------------------------
Figure out whether people are more likely to use a car with more fuel/charge.
This might be particularly interesting for electric vehicles and cities with
all-electric fleets (e.g.,do cars with 25-30% charge get orphaned until service
brings them in to charge?)
Also analyze when and where cars are refueled.
Based on cleanliness
--------------------
Show cars colour-coded by their reported cleanliness status to answer
the important question: do Kits people mark cars as dirty more frequently
than east van people?
Also, find and visualize cars that went from indicated 'unacceptable'
cleanliness rating back to 'good'. See how often and where that happens!
Other
-----
Get historical weather info and crunch basic stats to see if car2go
is more frequently used during bad weather. For bonus points, get weather
info automatically from city name and date/time of files being processed.
Wunderground can be used as basic source of data - historical info is free
on developer plan (500 calls per day, 10 per minute).
Visualize around special events - Canucks game, Whitecaps game, etc, etc?
See if we can pick up any additional events or activity.
Try to quantify environmental impact: how many cars does the service replace?
E.g.: one commute trip in the morning, one errand trip midday, one commute trip
in the evening, one nightlife trip during a given day would be replacing
one car, essentially. But if it had a second commute trip in the evening,
it might be replacing 1.5 cars. Just try to classify trips and
see how that breaks down, how many commute-like trips are made,
see if the data says any interesting things.
Traditional carshare visualizations
===================================
Current formats won't be very interesting with traditional model data.
Think of what would be good for this - perhaps a video/animation
that emphasizes cars being picked up, to stress usage?
Bus/transit visualizations
==========================
Not sure if this should be part of this codebase in general. I used to have
some support but it's been unused and untested for a while and some has been
removed. Improving it or removing it wholesale might be better.
If I get into this again, I will probably have to parse route info KMLs and
match bus positions to nearest stretch of route. A naive way might be to loop
through each pixel along route (generated from KML) and find closest bus.
Then colour the pixel with appropriate colour from the bus data.
HTML display
============
I can do some neat things given an interactive HTML page - switch time period
being displayed, switch display positions of trip start or end, etc.
If feeling fancy, can autogenerate list files on the hour or something.
HTML 5? Canvas? Just need to draw lines, shouldn't be demanding performance.