Any problem in map matching with accuracy about fmm HOT 7 CLOSED

The road network from real-world is complex and multi-dimension, especially in mega-cities. In my case, I find a major problem with accuracy is in the dual-line road. A trajectory might have point closes to a specific road segment, while also another point of this trajectory closes to the other road segment. This situation would result in an error that trajectory after map match could hold points both on the dual-line road at the same time.

from fmm.

@huangJianwei1119
Can you provide a screenshot of the problem?

from fmm.

Hi, I am sorry to reply so late.
The problem could be fixed by rebuilding a comprehensive network.

from fmm.

Hi, I have one high frequent GPS data, when i do matching, the results are not very good. The matching results are not continuous edges (i try many config parameters). So could you give me some help?

from fmm.

@Sean0719
Could you send me some example data set e.g., the road network and sample GPS data. I guess the problem could be the network topology is incomplete or there are some special type of noisy observations.
My email is cyang (at) kth.se

from fmm.

Hi, I already sent it. Thank you very much.

from fmm.

@Sean0719

I think the problem is that the topology of your network is incomplete. Some edges have the wrong direction.

The mr.txt file contains a field o_path, which is the edge matched for each point in the trajectory. But its complete path is missing, which implies that these matched edges in the o_path cannot be connected.

One example is shown below. Green is the original trajectory and blue is the edges matched.

As you can see, some edges are matched in a weird manner. The reason is that some edges have the wrong direction, or should be two way (The orange color below shows the road network).

I find that the osm network contains a one-way attribute, which is false for most of these links except some primary road. One solution is to create a reversed link for each of the edges whose one-way is false.

You may refer to this issue #21, which contains some postgresql codes for creating a reversed road network in a spatial database.

from fmm.