5 ms·
I don’t doubt this one bit. Here in Thailand I use grab at least once every day. Sometimes up to 4 times a day. Taxi to office, from office, meals, groceries,
by eric4smith 5y ago
I don’t doubt this one bit.
Here in Thailand I use grab at least once every day. Sometimes up to 4 times a day.
Taxi to office, from office, meals, groceries, courier service. Grab would not work without the army of motor bikes.
Just logging GPS every few seconds on a delivery to your home must be the vast majority of the data.
Transactions are probably the smallest amounts. Another big one is probably all the inventory records from supermarkets, convenience stores and restaurants in probably the number one foodie city in the world - Bangkok. Then there is taking photos to prove delivery pickups and drop offs. Damn…
Then travel to the Philippines, Vietnam, Indonesia - grab also just works. It’s actually quite an impressive operation and they’ve improved the app quite a bit in the last year alone.
Now with the lockdowns at the moment they are super busy more than usual - they probably up that amount of daily data by amount 50%
- monsieurbanana 5y agoSeeing how prevalent grab & foodpanda has become here in Singapore, I'd say much more than 50%.
- tpxl 5y ago> Just logging GPS every few seconds on a delivery to your home must be the vast majority of the data. Logging gps once per second every second of the day using two doubles will get you 691Kib of data. Unless you have two deliveries in flight 24/7 the math does not check out.
- chrismorgan 5y agoI believe precise GPS coordinates is 12 bytes per sample, so that’s ~1MiB/day. However, it compresses extremely well even with lossless content-unaware compression techniques (though I don’t have any real numbers), and if you’re serious about compression you can do even better still, with http://cs.joensuu.fi/~mchen/GPSTrajComp.htm http://cs.joensuu.fi/~mchen/GPSTrajComp.htm showing a technique that gets you down to ~3–6KiB per day if you’re happy with up to 10m of error.
- zarzavat 5y agoYou would only need to store the relative differences between the coordinates, so the actual precision is much lower than 12 bytes, even for a naive scheme.
- chrismorgan 5y agoFor correctness, I must note that if you’re using the usual static-size data types like floating- or fixed-point numbers, deltas take up roughly the same amount of space unless you impose speed limits, which allow you to get a bit cleverer about the space consumed, though it’s still complicated by the world being a sphere rather than flat. Notwithstanding that, when you get to compression, delta encoding does make it losslessly compress a bit better, though not as much as you might think, especially with the better compression algorithms. I simulated some stuff for this last year, but didn’t keep the answers I came up with. My extremely vague notion is that zip or gzip got something like a 10% improvement, but LZMA only saved another 1–2%. Don’t trust my numbers, though. And yeah, if you’re caring about this stuff you can do way better by a more deliberate encoding.
- zarzavat 5y agoIf you have a list of coordinates, then you know a priori what the maximum precision of the deltas is. If your delivery driver doesn't teleport at any point in the journey it's likely that you can shave quite a few bits off the top of each delta. For example, if your coordinates are precise to 1 angular meter, and the maximum delta in the list is 200 angular meters, then you only need 2x1 bytes for each coordinate.
- omegalulw 5y agoIt's not just your own GPS, they would log the driver car GPS too, so it's, on average, 4 coordinates per ride.