Closed JNatael closed 4 years ago
@JNatael is this a duplicate of #414? If so, can we close here and discuss the fix that's been proposed there?
It is indeed; closing now and I'll add a comment there. Wish I'd seen that yesterday; would have saved me some time. Thanks for the followup!
As noted in the StackOverflow question at https://stackoverflow.com/questions/61500820/osmnx-get-nearest-edges-function-results-unclear-on-which-key, I think the functions to find the nearest edge are missing a key (pun not intended) component ; namely the returning of the key as well as the nodes. In instances such as that discussed in the linked question, some nodes have multiple edges, and while the searching functions seem to find the correct edge, they report back only the end nodes of that edge, meaning there's no way for the user to identify which edge it is and leaving them likely to default to a wrong one.
If I missed some other way to get this information or am misunderstanding in some other way I'd love to know it, but as best I can tell this is basically a bug.
I have accordingly tried to tweak the two functions in question to correct this. The updated code is below and includes the necessary imports at the top so anyone else having this issue right now can drop it into their use case (I'm using it in a colab notebook) and then call these functions instead of those in the library unless/until the library gets updated.
I'm not sure if the approach I've taken is necessarily the one the library should do; it might make more sense to turn on the returning of keys as a default or have that be the only option since not having it opens the risk that a user will get wrong results. To maintain backwards compatibility for the moment though I've just added a flag that turns on the additional request for keys and made it optional to avoid breaking other code.
I'd have done this as a pull request as well, but my local python environment is having issues right now and I don't have time to do comprehensive testing; apologies for that. I also held off on any documentation update in favor of deferring to the library author about what approach to take. I've checked that this code at least works with the flag on and off for all three modes and I figure that's enough for the moment; hopefully still helpful in jumpstarting a fix.
Thanks again for a great library!