BUG: using GPS trajectory to find path with OSM results in multiple exceptions #10
Open
3 tasks done
Labels
bug
Something isn't working
PyTrack version checks
I have checked that this issue has not already been reported.
I have confirmed this bug exists on the latest version of PyTrack.
I have confirmed this bug exists on the main branch of PyTrack.
Issue Description
I am trying to check the sample as appearing in the documentation. for finding the path as it should be induced on OSM nodes.
I am using the following data :
all_points = [(42.343981, -83.068282),(42.344557, -83.06855),(42.345158, -83.068826),(42.345739, -83.069091),(42.346302, -83.069342),(42.346882, -83.06961),(42.347475, -83.069879),(42.348061, -83.070143),
(42.348634, -83.070406),(42.349217, -83.070679),(42.349808, -83.070997),(42.35039, -83.071336),(42.350993, -83.071686),(42.351586, -83.072038),(42.352192, -83.072393),(42.352813, -83.072754),(42.35344, -83.073121),
(42.354081, -83.073484),(42.354718, -83.073834),(42.355347, -83.07416),(42.355961, -83.074406),(42.356566, -83.074608),(42.357158, -83.074775),(42.357734, -83.074922),(42.358335, -83.074962),(42.358951, -83.07485),
(42.359548, -83.074571),(42.360128, -83.074126),(42.360585, -83.07362),(42.360991, -83.073111),(42.361731, -83.072093),(42.362051, -83.071603),(42.362373, -83.07109),(42.362699, -83.070568),(42.363038, -83.069994),
(42.363382, -83.069346),(42.363716, -83.068678),(42.364031, -83.068009),(42.364324, -83.067383),(42.364612, -83.066773),(42.364906, -83.066133),(42.365196, -83.065498),(42.365482, -83.064841),(42.365752, -83.064162),
(42.365985, -83.063562), (42.366205, -83.062984),(42.36638, -83.062431),(42.366498, -83.06189),(42.366559, -83.061304),(42.36657, -83.060721),(42.366535, -83.060186),(42.366487, -83.059704),(42.366442, -83.059258),
(42.366413, -83.05882),(42.366457, -83.058362),(42.366611, -83.057939),(42.366845, -83.057612),(42.367143, -83.057395),(42.367517, -83.057308),(42.367924, -83.057414),(42.368374, -83.057617),(42.368884, -83.057858),
(42.369424, -83.058138),(42.369975, -83.058455),(42.370521, -83.058753),(42.371084, -83.058982),(42.37172, -83.059162),(42.372423, -83.059326),(42.373146, -83.059485),(42.373877, -83.059694),(42.37461, -83.06005),
(42.375353, -83.06052),(42.376113, -83.061019),(42.376876, -83.061525),(42.37761, -83.062009),(42.378308, -83.062475),(42.378983, -83.062909),(42.379634, -83.063329),(42.380269, -83.063755),(42.380912, -83.064185),
(42.381564, -83.064626),(42.382227, -83.065073),(42.382888, -83.065521),(42.383551, -83.065964),(42.384226, -83.066415),(42.384914, -83.066879),(42.385623, -83.067359),(42.386344, -83.067846),(42.387071, -83.068332),
(42.387795, -83.068802),(42.388511, -83.069236)]
After getting candidates , I am getting some problems -
[1] The code itself throws many errors, on which I've no control, as it seems, some of them like math domain error, are quite an issue. This should be checked.
[2] For using the closest=True, after all if "finds" some path, which is not the correct one, as there is a jump between a highway, and another highway with different altitude.
[3] Using closest=False, results in no path found, which is something that I cannot comprehend at all. The idea is that giving more candidates at the first stage should results in more possible options, but certainly no diminish into a situation where "no solution is found".
This is the code :
after this calling the trellis and viterbi search, as in the sample, will result in the errors I am talking about.
note that in order to see the other problems one would need to set in the above to "closest=False"
Reproducible Example
Error Message
PyTrack/Python version information
last version
Additional Context
nothing to add
The text was updated successfully, but these errors were encountered: