BUG: using GPS trajectory to find path with OSM results in multiple exceptions

RaniRaven commented 1 year ago

PyTrack version checks

[X] I have checked that this issue has not already been reported.
[X] I have confirmed this bug exists on the latest version of PyTrack.
[X] 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

# Import libraries
import numpy as np
import pandas as pd

from pytrack.graph import graph, distance
from pytrack.analytics import visualization
from pytrack.matching import candidate, mpmatching_utils, mpmatching
# insert the "all_points" from the above explanation

#df = pd.read_excel("dataset.xlsx")
latitude, longitude = zip(*all_points)

#latitude = df["latitude"].to_list()
#longitude = df["longitude"].to_list()

points = [(lat, lon) for lat, lon in zip(latitude[:30], longitude[:30])]

# Create BBOX
north, east = np.max(np.array([*points]), 0)
south, west = np.min(np.array([*points]), 0)

# Extract road graph
G = graph.graph_from_bbox(*distance.enlarge_bbox(north, south, west, east, 500), simplify=True, network_type='drive')

# Extract candidates
G_interp, candidates = candidate.get_candidates(G, points, interp_dist=5, closest=True, radius=10)

Error Message

can run to see that

PyTrack/Python version information

last version

Additional Context

nothing to add

matteotortora commented 1 year ago

Actually, by running your code using the data you passed, I am able to generate the reconstructed path (in green), as you see attached: raven Any messages such as "math domain error" or "Node 1990592489 not reachable from 675307006" should not be considered as errors but as warnings. In fact, when generating the list of candidates for a real gps point, nodes that are not connected to any other point on the graph will also be included. Let me know if there are any doubts or other errors

RaniRaven commented 1 year ago

I'll look at this, as I've seen different results, but this looks somewhat promising.

cosbidev / PyTrack