search

owntracks / talk

Questions, talk about OwnTracks
32 stars 4 forks source link

Use of OwnTracks for bus service! #88

Closed mrose17 closed 3 years ago

mrose17 commented 4 years ago

hello! so here on the Grand Cayman island there is a "public" bus service, which consists of licensed drivers operating privately-owned vans going on a fixed route. there are two very nice features of this arrangement: first, if you're walking along a route and a bus comes by, you can waive at the driver, they'll pull over and let you board; and, second, sometimes they'll even backtrack a bit if you need to be dropped off shortly in the other direction.

for this discussion, let's assume that we can fork both the Android and iOS repositories to make (minor) changes...

Model

let's say there are two classes of users, drivers and rider, and that there's a route associated with each user.

the ACLs are set-up so that drivers can see all the messages for the drivers and riders in the route. so they can see how many folks are up ahead and what other drivers are active on the route.

instead, riders can see only those messages for the drivers. this will let them know which drivers are headed in their direction.

Environment

  1. we expect that a driver has their phone plugged into their vehicle's power: OwnTracks will have monitoring: 2 (move) configured. we also expect that the mobile OS will allow OwnTracks to provide location updates whether or not the app is in the foreground.

  2. we expect riders to be untethered from power.

Questions

  1. for riders (where battery usage may be an issue) does it make sense to use monitoring: 1 (significant)? similarly, should the mobile OS be configured to allow location updates only when the app is in the foreground?

  2. under what circumstances do locatorDisplacement and locatorInterval come into play? i'm going to guess only for monitoring: 2 ...

  3. the information shown should be "current". since ignoreStaleLocations is denominated in integer-valued days. that's something of an issue. i wouldn't mind writing something that monitors locations and does "something" when the message is deemed stale. the question is "what is that something"?

thanks for any pointers!

ckrey commented 4 years ago

  1. It is easy to toggle modes. So a rider can select when they want to hitch a ride.

  2. we can consider changing ignoreStaleLocations to be interpreted as a float value. This would allow to ignore all positions older than a few e.g. minutes.

mrose17 commented 4 years ago

thanks! let me ask a few clarifying questions...

  1. if we were to have riders be configured for monitoring: 2 but also have their mobile OS give location access only when in the foreground, would that be workable in terms of frequent updates?

  2. i expect that locatorDisplacement and locatorInterval are useful only in the Android app, since there is no mobile OS support for SLC, and Android emulates it by setting those two values appropriately. (also, i don't see anywhere in the iOS code where those parameters are actually used, other than being recorded and displayed.) is that correct?

  3. i will run a local copy of OwnTracks with iOS and see how a floating value for ignoreStaleLocations works out. what do we think is a good value for this domain? 3m for the rider configuration (0.0021 and 5m for the driver configuration (0.0035) ?. this will probably require some tuning, i imagine...

  4. does anything else spring to mind to configure?

thanks!

jpmens commented 3 years ago

Closing as stale