Databases Reference
In-Depth Information
Figure 8-9. Conceptual flow diagram for GPS tracks
The following data shows some of the results near our geohash
9q9jh0
example. Note
how the
9q9
prefix identifies neighboring geohash values:
?uuid ?geohash ?gps_count ?recent_visit
342ac6fd3f5f44c6b97724d618d587cf 9q9htz 4 1972376690969
32cc09e69bc042f1ad22fc16ee275e21 9q9hv3 3 1972376670935
342ac6fd3f5f44c6b97724d618d587cf 9q9hv3 3 1972376691356
342ac6fd3f5f44c6b97724d618d587cf 9q9hv6 1 1972376691180
342ac6fd3f5f44c6b97724d618d587cf 9q9hv8 18 1972376691028
342ac6fd3f5f44c6b97724d618d587cf 9q9hv9 7 1972376691101
342ac6fd3f5f44c6b97724d618d587cf 9q9hvb 22 1972376691010
342ac6fd3f5f44c6b97724d618d587cf 9q9hwn 13 1972376690782
342ac6fd3f5f44c6b97724d618d587cf 9q9hwp 58 1972376690965
482dc171ef0342b79134d77de0f31c4f 9q9jh0 15 1972376952532
b1b4d653f5d9468a8dd18a77edcc5143 9q9jh0 18 1972376945348
Great, now we have a data product about areas in Palo Alto that are known to be walk‐
able. Over time, a production app might use this evidence to optimize the workflow.
Recommendations
The last part of this app is the actual recommender. As mentioned earlier, most of the
code in the workflow is used for data preparation—recall the 80/20 rule about that.
When it comes to the actual recommender, that's just a few lines of code:
(
defn
get-reco
[
tracks
shades
]
"subquery to recommend road segments based on GPS tracks"
(
<-
[
?uuid
?road
?geohash
?lat
?lng
?alt
?gps_count
?recent_visit
?road_metric
?tree_metric
]
(
tracks
:>>
gps-fields
)
(
shades
?road
?geohash
?lat
?lng
?alt
?road_metric
?tree_metric
)))
Mostly this involves a join on
geohash
fields, then collecting road segment metrics for
each user—based on the
uuid
field. Due to the sparseness of geo coordinates in practice,
that join is likely to be efficient. For example, if the mobile app using this data gains
