Heterogeneous traces: how to deal with them?

[Bernd Welter]

HI there,

one of our customer gathers GPS positions on the device with a proper density of the signal.
As the network traffic is a crucial topic for them they would like to filter some of the positions based on some kind of "no relevant change since the last record" (e.g. staying on a highway for one hour might not require a confirmation every 10 seconds).

The idea is simple but the API offers more or less just one shared "matching algorithm" within a single transaction: either "sparse" or "dense".

How can we deal with such a constraint? Do we have experience and what is PTVs recommendation?

Best regards,
Bernd

[Joost]

The question is more how reliable should the result be?

If you can accept some mismatches you can run in local mode ( In the profile set Mapmatching / HistoryConsideration / @enabled to false). The is does not matter how far or how close the points are from each other.

If you do not want to accept some mismatches you have to run in global mode (Mapmatching / HistoryConsideration / @enabled set to true). This also means you need to give to algorithm enough search space to go from one position to the next. The search space is limited by the Mapmatching / Crawler element.

In global mode you can state that their is a relation between the size of the search space and the time and memory xMapmatch need to process a request. This used to be exponential and i used to advice to have the polling interval on max 2 min, but with the 1.26 version the crawler was extended with a aStar search functionality functionality. Because of this the relation has become much more linear. Technically it is still exponentially but the exponent is much lower so it mimics linear behavior.

I have not yet pushed the xMapmatch 1.26 to it's limits so I do not know how far you can go with this.

[johannesstober]

I agree completely with the response of Joost.

Of course when we have only the possibility to drive straight forward, there's no performance problem. But after every exit we have a lot of possibilities - not only to exit the motorway itself, but subsequently at every small junction. Like Joost describe we get in an exponential runtime.

Therefore in the xmapmatch profile a parameter called maximumCrawlingJunctionCount is defined. Its default is set to 8, because we are sure, that we don't run into performance problems for this count of junctions. Obviously the distance between 8 junctions is higher on motorways than on urban streets. But also on motorways we must consider, that there are country roads with some junctions after every exit we have to check. Maybe using the A* algorithm in version 1.26 we can increase this value (e.g. to 12).

If the customer is able to detect the type of the current street, it is possible to descrease the count of signals sending to the xMapmatch. But nevertheless there's a boundary, which must not be exceeded.

Because of A* algorithm the behaviour of the xMapmatch became better. But up to now we didn't check which signal rate is possible by ensuring acceptable performance. Intuitive I agree with the statement of Joost, that the interval shouldn't exceed 2 minutes (resp. 4 km) on motorways. But without stress tests no binding statements from my side...