Strange matching behaviour

[KZsolt]

Helo guys!

I've started to use the XMapmatchServer and I currently face a strange issue that I can't fix on my own.

When I plan the example route with the data that you guys provided in the cookbook session (http://xserver.ptvgroup.com/fileadmin/f ... htm#output), I get a valid route as a result of the matching.
But only a couple of points gets matched to a road when I use a different array of waypoints.

The original array of waypoints:

The points that are matched by XmapMatch:

(The google maps pictures are only for representation)
What can cause this behavior and how can I fix it?
We are using the EuropePremium_2014_2H.geo map, with the default profile in callercontext.
The calling method: *client*.matchTrackExtended(*trackpositions*, null, true, true,*cc*)

If you want I can also send the .kml file with the test results. (For that please provide me an e-mail address I can use.)

Thank you,
Kiraly Zsolt

[Joost]

Within xMapmatch there is a high need to make sure the profile you are using is configured to match the properties of your signal. Properties of your signal are for example your polling interval, accuracy of the GPS, etc. With the "wrong" profile you will quickly end up with a bad quality result, be it wrong matches or hardly any matches.

If I look at the picture you are of your input I'm guessing your polling interval is somewhere around 2 to 3 minutes. Our default profile is configured for a much smaller polling interval. This is way you are getting a bad quality result.

One of the big factors in the profile witch influence this behavior is if you are running in "local mode" or "global mode". Local mode means that each point is only matched using the data of the point itself. Internally the xMapmatch will come up with a number of candidates and return the best candidate it is confident about. Global mode goes further and will also rate the candidates based on how likely they are to be reached from previous candidates and how likely they are able to reach next candidates. You can enable global mode with the Mapmatching / HistoryConsideration / @enabled attribute of the profile.

The moment global mode is enabled (which is the case in our default profile) the following 2 element of the profile become important: HistoryConsideration and Crawler. Explaining the 2 elements in a nutshell:
* Crawler will configure how the xMapmatch will look in the map for a possible road between elements. It sets limits how far the algorithm should look for the next match.
* HistoryConsideration configures how the xMapmatch will evaluate a point based on the previous points. For example how many candidates do you keep for each input to use for global matching later.

When dealing with global matching it becomes crucial that you properly configure these elements. If you set the limits to low you will end up with almost no results. If you set the limits to high performance drops completely. Off coarse signals with a big polling interval need high limits to get from a input point to the next point. With big polling intervals it them becomes very hard to get global mode usable with a reasonable performance. My rule of thumb is that global mode is doable until a 2 min polling interval.

Coming back to your signal, I would recommend to first start with global mode disabled. You can use the local-matching profile that is delivered with the xMapmatch. It gives you a profile with which you can experiment a bit and get a feeling for the data before diving completely in global mode. If you are ready for global mode, I would recommend to start of testing with relatively small tracks (let say about 20-25 points) so you can start up with high limits (and then slowly restricting them) witch will finish in a somewhat reasonable time.

[KZsolt]

Dear Joost,

Thank you very much for the detailed explanation!
That helped me a lot to solve most of the problems I faced.
The only question I still have is simple:
When using the local-matching profile, is there any way to set the preferred network class for the algorithm?
In some case the input coordinate gets matched to a road from lower network class instead of a (preferred) higher one. Even if the distance is equal from the input coordinate.

I've attached a picture which shows the example point matches.

Thank you,
Kiraly Zsolt

[Tobias Bachmor]

Hi,

there is no such thing as a restriction to specific network classes within the map matcher. So the map matcher should match to the closest road available - if the attributes match. Maybe the heading is wrong?
One thing you could try is reducing the linking distance. This is something you can always do when you know that you have quite a good signal.

Best regards,

Tobias