Checkinout table

[allenmichael099]

Made the a table tab to display bike checkins as a serparate tab from participants and trips.

From my commit:

• Added function query_checkinout to utils_query_databasee
• Added the checkinout field to data_r in mod_load_data
• called mod_DT_server using data = data_r$checkinout
• added a tabPanel for "Bike Check In" to app_ui
• moved the assert_flag for anon_locations within run_app

[shankari]

Seems like it should all work. Hopefully R has a way to retrieve keys by name (e.g. the equivalent of data[t["name"]]). I'm not sure if the data_r$t["name"] would work 😄

[asiripanich]

Seems like it should all work. Hopefully R has a way to retrieve keys by name (e.g. the equivalent of data[t["name"]]). I'm not sure if the data_r$t["name"] would work 😄

Yes, that works in R as well data_r$t[["name"]].

[asiripanich]

@allenmichael099 Once I merge #32 to master, could you please pull new commits from master to this branch? Thanks

[allenmichael099]

After merging, I ran into an issue related to tidy_cleaned_trips and am currently looking into it. My first error was: Warning: Error in setorderv: some columns are not in the data.table: data.end_fmt_time

[allenmichael099]

So the difference is within query_cleaned_trips: my working version said analysis/cleaned_trip, but after I merged it said analysis confirmed_trip, which returned a null data frame %>% null data table %>% couldn't use setorder. I'm not sure whether or not this has to do with differences between test-data and the actual data set.

There also is an issue just before generate trajectories so that when generate_trajectories is called, tidied_trips is missing 'fmt_time_utc', which gives: Warning: Error in eval: object 'fmt_time_utc' not found

[shankari]

@allenmichael099 aha! As part of https://github.com/asiripanich/emdash/pull/23 I switched to reading confirmed_trip instead of cleaned_trip I also updated the test database

You need to update your test mongodb and then everything should work 👍 This will also display mode_confirm, purpose_confirm etc in the trip table

[allenmichael099]

@shankari Got it, thanks! I changed cleaned trip back to confirmed trip and downloaded the new test data. Everything looks like it works now

[shankari]

@asiripanich I am going to merge this into a local branch for deployment now

[shankari]

This works great barring the sync between the table and the plot. I even enabled the commented out "Polar Bear" table and it worked just fine.

[shankari]

Looked at the table with the end user today, and everything is fine except that the timestamp is in milliseconds. We should really handle that in the dashboard instead of forcing the user to convert manually.

There are two ways in which we can do this:

• convert on the client (perhaps automatically by looking at fields called ts)
• store the formatted time on the server

In both cases, we need to decide how to specify the timezone for the conversion

One option is to have the phone send up the formatted time and the timezone, similar to the current background sensed entries. This would require no further customization on the dashboard.

[shankari]

Timezones are tricky to work with. The classic solution for time display is that you store everything as a ts and convert at the presentation layer, before displaying to the user. BUT when you display to the user, which timezone should you use?

• no timezone = UTC = time in GMT. This is what AWS etc do, for example. This will be the same no matter where in the world you view it from, which is great for consistency, but requires the user to do mental math to figure out the conversion to their local timezone.
• timezone of the viewer. you can determine this from the computer/browser settings and just convert. This is what most TZ aware code (e.g. Github) does.
• timezone of the checkin/out. So if the user checked out in MDT, show this in MDT even if the viewer is in PDT. That's what we do with the trip start/end. If we want to do this, the fmt time and/or the timezone have to be generated from the app and stored along with the timestamp.

[shankari]

This is only really applicable to app-generated supplementary data. Not sure how common a use case that is, and how people are going to want to use it in the future. Let's not overengineer. If @allenmichael099 can get the formatted time in the timezone of the computer along with automatically converting all ts columns, that is good enough for now.

If we need to send fmt_time from the app, we can migrate the server side data later.