This is an old problem in multiplayer games. The usual solution is that the sending client predicts the position linearly from the last two fixes, and when the actual position differs from the prediction by some constant amount, it sends an update. The receiving end uses the same prediction algorithm, so its positions match the sending end with a maximum error of the same constant amount, (plus some additional error due to lag.) Updates are also sent periodically in case one gets lost, but those are not frequent.
Incidentally, Uber's display of cars on a map on the home screen is totally fake.
If we're talking FPS games:
The local player is moved instantly based on their local inputs, and the server will also move them using the same rules. The local player will be corrected in any case where they don't match.
For other players that the local player sees, extrapolation in twitchy multiplayer games like FPSs is notoriously bad as the players are so hard to predict, so usually you have them running e.g. 100ms behind so you can (hopefully, depending on latency) interpolate between two data points from the server instead of trying to guess the future at all. So you still have the "behind real time" problem. The only reason the local player can avoid that is they have the benefit of local inputs. In an Uber sense they are the car.
Obviously that's a problem in games too, because now the player is shooting someone who's behind where they are on the server, so they miss. Latency Compensation fixes that - having the server rewind time to see what the client would have seen. But that won't help the cars-on-a-map problem.
Having said all that, I do agree with your point. Taking a couple of old data points and extrapolating from there should work pretty well for the cars problem. You'll see them snap back when they stop at intersections though.
The fanciness regarding position, why not show a halo like most gps apps showing degree of accuracy?
You could all show a slight tail of previous path to give an idea of direction and speed.
I think the current uber/lyft ui experience is subpar and can be improved.
(Not that I've got a dog in the fight any more, don't forget today's the day to delete Uber!)
Here is a demo we threw together of it working in real life: https://youtu.be/7ALHtbC9aOM
Here is a prototype of saving 100M+ writes for $10/day: https://www.youtube.com/watch?v=x_WqBuEA7s8
Our sync system: https://github.com/amark/gun
And since we are on the topic, I highly recommend this engineering blog post by Discord on how they scaled up append-only writes in a way similar to how our system does: https://blog.discordapp.com/how-discord-stores-billions-of-m... .
By the way GunDB looks really cool. Nice!
- a car-game-like 3D interface where you can see the view from the driver's seat, moving at the actual sensed speed of the car, with fake (or Street View) scenery whizzing by, so while you are waiting you can see that the driver is actually moving at close to the speed limit.
- render a bunch of other random cars on the road, emulating the actual real-time density of traffic, so if the guy is chugging along slowly I as the user will blame the traffic, not the app or driver
- render rain and snow in the 3D view if that is what is slowing the driver, so I will curse at the weather for creating an unsafe situation and not the driver for going slow
- render ambulances and police cars in the 3D view if a traffic accident is reported, so i will understand that a human is hurt instead of cursing at the Uber app
- show the state of red lights in real time so that when a driver is stopped i know it is for a red light and not lazing around or lost directions. there are enough Uber cars driving around that based on aggregate GPS statistics they should be able to determine the cycle times and phases of every traffic light on major streets.
sorry but regardless of the UI, does this scenario even make any sense? why would your driver be going extremely slow unless there was a good reason for it? I agree that the UI can be a bit misleading with speed but i think this is a bit much
On browsers I'm using turf.js to calculate movements and then animate them. I calculate where the bus/train is likely to be in the next 30 seconds, and then send that data through to the user. Then I keep updating the vehicle marker frequently until that 30 seconds time out, or until another update comes in.
I'm struggling to do the same on Android because I haven't found a good turf.js equivalent there.
Update: Here are React-Native Map components for Android and iOS https://github.com/airbnb/react-native-maps
OpenStreetMap license requires you to display an attribution though.
See here: http://wiki.openstreetmap.org/wiki/OpenLayers_Local_Tiles_Ex...
You could also further reduce data by indexing the city into a grid, of, say 1 meter squares, or potentially a hilbert curve would be fun to experiment with.