I have two questions about matching details。 about leuvenmapmatching

[wannesm]

That should indeed not happen. Given your second question, that might be the reason. I might not understand the second question, but the trajectory should be in chronological order. If the tracked object is moving back and forth on the same road it might pick different routes depending on the noise on the signal. The default settings try to avoid a matching that goes back and forth on the same route (because that's more likely to be due to noise than the actual behaviour).

[angelyix]

That should indeed not happen. Given your second question, that might be the reason. I might not understand the second question, but the trajectory should be in chronological order. If the tracked object is moving back and forth on the same road it might pick different routes depending on the noise on the signal. The default settings try to avoid a matching that goes back and forth on the same route (because that's more likely to be due to noise than the actual behaviour).

Thank you for your reply, that is exactly what I mean. However, I have another question today :(
I have some track points that seem pretty clear about which road segment they should belong to, but the result is confusing. I have checked that the map obtained through Osmnx package has drivable roads in this part, I wonder if the result can be improved by adjusting the parameters of the algorithm.

[wannesm]

My first guess would be that the edges for that street are missing from the map used by the algorithm. You can visualize the edges that are available by setting show_graph=True in the plot method.

[angelyix]

My first guess would be that the edges for that street are missing from the map used by the algorithm. You can visualize the edges that are available by setting show_graph=True in the plot method.

Hi, developer! It is the reason for my previous question, thanks for your reply. I found another question about matching details: Matching results are not complete, the algorithm stops when it reaches a GPS point, and it seems that an error has occurred at the point. I checked the road network, the road network around here is complete and the GPS track is in chronological order, I don't know why the matching cannot continue.

[wannesm]

This still looks very much like a disconnected graph. In some graphs (e.g. from OpenStreetMap) one can have two nodes on top of each other if map makers forget to connect them. I'd advise to go into the database or the map object and query for the last two nodes that are matched. I suspect that the second to last matched node (where the path makes a 90 turn) only has 3 neighbors or less instead of the 4 that are expected.

You can print the last three matches using print(matcher.lattice_best[-3:]). This should show also the names of the nodes that you can use to search the map. For example:

>>> matcher.lattice_best[-3:]  # Get last three matches
[1545679251-20910628-14-0, 1545679251-20910628-15-0, 20910628-3663115130-16-0]
>>> matcher.lattice_best[-2].edge_m.l2  # Get the second label in the second to last matched edge
20910628
>>> [label for label, coord in map_con.nodes_nbrto(20910628)]  # Query graph for neighbours
[3663115130, 1545679251, 20910628]

[angelyix]

This still looks very much like a disconnected graph. In some graphs (e.g. from OpenStreetMap) one can have two nodes on top of each other if map makers forget to connect them. I'd advise to go into the database or the map object and query for the last two nodes that are matched. I suspect that the second to last matched node (where the path makes a 90 turn) only has 3 neighbors or less instead of the 4 that are expected.

You can print the last three matches using print(matcher.lattice_best[-3:]). This should show also the names of the nodes that you can use to search the map. For example:

>>> matcher.lattice_best[-3:]  # Get last three matches
[1545679251-20910628-14-0, 1545679251-20910628-15-0, 20910628-3663115130-16-0]
>>> matcher.lattice_best[-2].edge_m.l2  # Get the second label in the second to last matched edge
20910628
>>> [label for label, coord in map_con.nodes_nbrto(20910628)]  # Query graph for neighbours
[3663115130, 1545679251, 20910628]

Thanks for your reply, it helped me a lot. Did you try other map graphs except for the OSM obtained by Osmnx or are there other ways to get a more complete road network? Because I found there are many disconnected roads on the map graphs obtained by Osmnx, leading to incorrect matching results.

[Shawn94]

This still looks very much like a disconnected graph. In some graphs (e.g. from OpenStreetMap) one can have two nodes on top of each other if map makers forget to connect them. I'd advise to go into the database or the map object and query for the last two nodes that are matched. I suspect that the second to last matched node (where the path makes a 90 turn) only has 3 neighbors or less instead of the 4 that are expected.
You can print the last three matches using print(matcher.lattice_best[-3:]). This should show also the names of the nodes that you can use to search the map. For example:

>>> matcher.lattice_best[-3:]  # Get last three matches
[1545679251-20910628-14-0, 1545679251-20910628-15-0, 20910628-3663115130-16-0]
>>> matcher.lattice_best[-2].edge_m.l2  # Get the second label in the second to last matched edge
20910628
>>> [label for label, coord in map_con.nodes_nbrto(20910628)]  # Query graph for neighbours
[3663115130, 1545679251, 20910628]

Thanks for your reply, it helped me a lot. Did you try other map graphs except for the OSM obtained by Osmnx or are there other ways to get a more complete road network? Because I found there are many disconnected roads on the map graphs obtained by Osmnx, leading to incorrect matching results.

Hi! Have you solved this problem? If yes, how did you manage to solve it? I have the same issue as above, on some point, matcher stops matching with given gps coordinates.

[angelyix]

This still looks very much like a disconnected graph. In some graphs (e.g. from OpenStreetMap) one can have two nodes on top of each other if map makers forget to connect them. I'd advise to go into the database or the map object and query for the last two nodes that are matched. I suspect that the second to last matched node (where the path makes a 90 turn) only has 3 neighbors or less instead of the 4 that are expected.
You can print the last three matches using print(matcher.lattice_best[-3:]). This should show also the names of the nodes that you can use to search the map. For example:

>>> matcher.lattice_best[-3:]  # Get last three matches
[1545679251-20910628-14-0, 1545679251-20910628-15-0, 20910628-3663115130-16-0]
>>> matcher.lattice_best[-2].edge_m.l2  # Get the second label in the second to last matched edge
20910628
>>> [label for label, coord in map_con.nodes_nbrto(20910628)]  # Query graph for neighbours
[3663115130, 1545679251, 20910628]

Thanks for your reply, it helped me a lot. Did you try other map graphs except for the OSM obtained by Osmnx or are there other ways to get a more complete road network? Because I found there are many disconnected roads on the map graphs obtained by Osmnx, leading to incorrect matching results.

Hi! Have you solved this problem? If yes, how did you manage to solve it? I have the same issue as above, on some point, matcher stops matching with given gps coordinates.

I' m sorry. I haven't solved this problem yet. I am still using map graphs form the OSM obtained by Osmnx, and some of the paths don't match.