How doesNetwork algorithm choose which points to use?

[dunande]

I was playing around with Networks and made 3 tracks that overlapped pretty closely, then a fourth track that mostly overlapped but strayed off course for the last 10% or so of the track.   In default mode, the 4 tracks become one, nicely, and gave me a branch for the 10% as expected.   So when I cranked up the contraction, I then got one track but for the area where the one track was off, the algorithm chose the single tracks' data instead of the 3 that are close.  I would have expected it to have been the other way around.  This explains some other anomalies I've seeing in my networks (like where I have a low-resolution track that doesn't display a corner very well, networked with a high resolution track that does - I frequently see it choose the low-resolution track).

[dunande]

Just another note on this.  To make sure that that segment hadn't gotten averaged, I went back and enabled the maps that were networked and sure enough, that segment followed exactly the stray line in the networked track.

[ScottMorris]

Hmm, the way 'contractions' are handled is a bit tricky.  I think that when there is a node that has a bunch of 'spurs' hanging off, all of which are shorter than the contraction threshold, it simply picks and keeps the longest one.  There's no attempt to choose the most 'central' one.  Usually this case arises at a trailhead, where a bunch of tracks will start, but not at the exact same spot.  Choosing the longest one seemed like a logical way to choose.  I suppose the more central one might be better, or an average of them all.

The type of anomaly you are describing with corners is more a product of the imperfect averaging.  Averaging works well with a small number of tracks.  It gets tricky beyond that.  With turns (esp. switchbacks) your data has to be really good/close/accurate for the turn structure to come out well.

I am working on a new technique that post processes the network and chooses the most central of all tracks as the average to use in the resulting network.  So far this is the best way to preserve tight turns and still get the most accurate/central data possible.  The problem is that often turns are of smaller 'resolution' than the average GPS error in the area.  Any smoothing/averaging algorithm will straighten things out because the turn looks like noise, not a salient feature.  I think that's why you are seeing corners cut and smoothed out.