Comments (3)
So Uber didn't have H3 for a long time after it started. At first it was pretty simple: shard based on political boundaries (city/county/etc) where the pricing differs and keep all of the drivers indexed by that (there weren't really that many). Then take the rider's lat, lng and the drivers' lat, lng values, subtract them to get the delta-lat and delta-lng for each, multiply the delta-latitude by a constant based on one of the latitudes to roughly "square up" versus the longitude to avoid distance distortion (or just ignore it at first if you're relatively close to the equator, it only matters very far north), and then square the deltas and add them together, then sort the drivers by this ranking and you have them by distance from the rider.
With a small number of drivers, doing this in a tight loop is more efficient than any database-driven indexing approach. When you have a ton of potential riders and drivers you can do something trickier, but for Uber-style dispatching, the right next move isn't going to H3, it's using OSRM to calculate ETAs from the drivers to the rider and sorting by that, so you don't accidentally dispatch drivers across a river with few bridges.
Once OSRM is showing some signs of strain would you introduce something like S2 or H3 to do rough bucketing like you've described, but then you just feed that subset of drivers to OSRM because distance "as the crow flies" is not the best approach when cars don't fly.
In conclusion, for actual Uber-style dispatching, H3 is the last kind of micro-optimization you might need when you have a ridiculous volume of requests.Thank you A LOT! I was in this dilema hahaha, because I currently plan to have +5000 drivers and the database will be slow when comparing distances between all those drivers. That's why I wondered in those two approaches and then calculate, as you said, the route with OSRM to determine the best driver.
Thank you!!
No problem. I would also recommend keeping just the driver location data in a fast, simple nosql DB like Redis with their ids grouped by whatever basic sharing strategy you have. It's basically ephemeral data so no point in slamming your main DB that probably persists all updates to disk and killing its performance.
from h3-js.
So Uber didn't have H3 for a long time after it started. At first it was pretty simple: shard based on political boundaries (city/county/etc) where the pricing differs and keep all of the drivers indexed by that (there weren't really that many). Then take the rider's lat, lng and the drivers' lat, lng values, subtract them to get the delta-lat and delta-lng for each, multiply the delta-latitude by a constant based on one of the latitudes to roughly "square up" versus the longitude to avoid distance distortion (or just ignore it at first if you're relatively close to the equator, it only matters very far north), and then square the deltas and add them together, then sort the drivers by this ranking and you have them by distance from the rider.
With a small number of drivers, doing this in a tight loop is more efficient than any database-driven indexing approach. When you have a ton of potential riders and drivers you can do something trickier, but for Uber-style dispatching, the right next move isn't going to H3, it's using OSRM to calculate ETAs from the drivers to the rider and sorting by that, so you don't accidentally dispatch drivers across a river with few bridges.
Once OSRM is showing some signs of strain would you introduce something like S2 or H3 to do rough bucketing like you've described, but then you just feed that subset of drivers to OSRM because distance "as the crow flies" is not the best approach when cars don't fly.
In conclusion, for actual Uber-style dispatching, H3 is the last kind of micro-optimization you might need when you have a ridiculous volume of requests.
from h3-js.
So Uber didn't have H3 for a long time after it started. At first it was pretty simple: shard based on political boundaries (city/county/etc) where the pricing differs and keep all of the drivers indexed by that (there weren't really that many). Then take the rider's lat, lng and the drivers' lat, lng values, subtract them to get the delta-lat and delta-lng for each, multiply the delta-latitude by a constant based on one of the latitudes to roughly "square up" versus the longitude to avoid distance distortion (or just ignore it at first if you're relatively close to the equator, it only matters very far north), and then square the deltas and add them together, then sort the drivers by this ranking and you have them by distance from the rider.
With a small number of drivers, doing this in a tight loop is more efficient than any database-driven indexing approach. When you have a ton of potential riders and drivers you can do something trickier, but for Uber-style dispatching, the right next move isn't going to H3, it's using OSRM to calculate ETAs from the drivers to the rider and sorting by that, so you don't accidentally dispatch drivers across a river with few bridges.
Once OSRM is showing some signs of strain would you introduce something like S2 or H3 to do rough bucketing like you've described, but then you just feed that subset of drivers to OSRM because distance "as the crow flies" is not the best approach when cars don't fly.
In conclusion, for actual Uber-style dispatching, H3 is the last kind of micro-optimization you might need when you have a ridiculous volume of requests.
Thank you A LOT! I was in this dilema hahaha, because I currently plan to have +5000 drivers and the database will be slow when comparing distances between all those drivers. That's why I wondered in those two approaches and then calculate, as you said, the route with OSRM to determine the best driver.
Thank you!!
from h3-js.
Related Issues (20)
- Openlayers instead of Mapbox HOT 1
- Count the number of points in the aggregated bins of H3-hexagons HOT 3
- Upgrade emscripten to 3.X.X? HOT 7
- Integrating with google maps HOT 1
- How to replace firestore geofire with h3? HOT 3
- Potential memory leak in polygonToCells HOT 10
- Load and Display H3-JS binned dataset in Mapbox HOT 1
- Consider buffer radius in addition to H3 resolution when counting points in the aggregated bins of H3-hexagons HOT 2
- Inverted coordinates HOT 1
- H3-JS binning resoluion in OpenLayers HOT 1
- Incorrect result from polygonToCells for bigger screen/ higher dimensions HOT 6
- Error when passing zero area polygon to h3.polygonToCells HOT 2
- Does h3-js send any data to the server? HOT 1
- I am unable to load h3-JS in my quasar project HOT 3
- H3 with dynamodb
- Different output from h3-js and postgis using cellToBoundary function HOT 1
- Hexagons Resolution HOT 1
- Somthing is funky at the borders of the cells HOT 1
- Novice h3-js lib installation issue HOT 1
- polygonToCells fails for some simple large polygons HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from h3-js.