-
Notifications
You must be signed in to change notification settings - Fork 2
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Determine user's current road #4
Comments
I found a potential solution using Nominatim, which is an OpenStreetMap API that contains a reverse-geocoding function. It gets the nearest address node to the inputted coordinates. I'll work on improving the function to catch edge cases, errors, etc. The obvious limitation that the nearest node may be a significant distance from the coordinates, and therefore give the wrong street, however, there may be other ways of improving this accuracy. Edit: Currently looking into Valhalla and Meili as suggested in the linked medium article |
Thanks! Nominatim might give us a decent answer much of the time,, but it's not really geared towards the problem of matching a moving point to a road. OpenStreetMap has an API more suitable for this (http://project-osrm.org/docs/v5.22.0/api/?language=cURL#match-service). But more importantly, it shouldn't be necessary to query an external API for this at all. The app is constantly fetching local OpenStreetMap tiles containing all relevant GeoJSON features, so the necessary data should already be on the device. The open question is how to choose which local road is the right one, and I was hoping the Python code snippets in the linked Medium article might translate to JavaScript. Basically, the input would be a handful of recent GPS points (like HeadingCalculator uses in app/js/spatial/heading.js) and the local OSM features filtered down to just roads (see nearbyFeatures in app/js/audio/callout.js). If we're lucky, the Turf.js library we're using for geospatial calculations already implements some of the geometry features used by the documented algorithms. Want to give one of those a try? |
Ahh I see, I was wondering about how the tiles worked. I'll definitely look into it more today, and hopefully I'll work something out with Turf, if not I'll mess around with the libraries in the medium article. |
I believe we've found a relatively accurate solution, and it has currently been implemented here: The function now uses tile data and turf.js functions to determine the nearest points (snap points) on all nearby roads. If the location is near an intersection (i.e. two roads within under 5 meters) it returns both the nearest 2 roads. |
Nice work! If you open a pull request, I can give some feedback on the specific changes. I'll note that returning multiple roads when near an intersection isn't ideal, since the first use of this information was going to be to improve intersection announcements, i.e. instead of just saying "intersection: A street, B street" we'd prefer to say "A street continues ahead, B street goes right". One way to fix this might be to just look back a few points to the last unambiguous current-road reading. |
We now have nearest roads thanks to #11, but we'll need some additional logic to establish when a user is actually on a road, and also to use that to make intersection announcements more specific. |
Determine what road the user is currently traveling along. This is a somewhat nontrivial problem known as map matching. Are there libraries to do this in JavaScript?
The text was updated successfully, but these errors were encountered: