I get the impression it’s a tad more responsive but i can’t really tell.
1 Like
I didn’t notice any obvious difference between this version and the previous one.
1 Like
Actually the original code for dotted tracks is completely broken and not logical.
I’ve tried to make it much more consistent.
The stale timeout is set to 15 seconds for mlat and 8 seconds for GPS positions.
If the last position is longer in the past than that, the line will be drawn dotted.
You could reduce that somewhat but i think both values are fair.
For loading the initial history the time between valid positions can be greater without the track being broken.
This is necessary for long history intervals.
I could make that allowance somewhat shorter i think.
1 Like
Here’s a comparison of an MLAT track between the two. Your version has a more consistent trail.
When the police helicopter comes out to play later, I should get some good tracks to compare since it’s always at about 1000 feet, so the trail is sometimes broken quite a bit.
1 Like
Well it’s more forgiving, which isn’t always a good thing.
Marking the track dotted is to let you know that no position was received between those two positions.
But in the original webinterface the code is bugged.
Still you could make an argument to make dotted tracks for GPS positions longer than 5 seconds and MLAT positions longer than 10 seconds apart.
(instead of 8 and 15)
1 Like
Possibly - you get more information by having intervals shorter, but it doesn’t look as neat. I suppose it depends if you want a representation of the aircraft’s path or an indication of where you have some dead spots in reception.
1 Like
Thanks 
I’ve got no intention, it works perfectly, thanks.
1 Like
I installed it and pretty interesting to have but…for a dummy like me editing the /usr/local/share/tar1090/html/layers.js is a little bit much for me. I would like to have all the layers. Outside of that all your 1090 FA add ons are excellent.
1 Like
Can you describe the bug?
1 Like
Maybe my memory was wrong there, the code is written somewhat confusing.
One thing that is problematic though:
this.position = [data.lon, data.lat];
PlaneObject.prototype.updateTrack = function(estimate_time) {
if (!this.position)
return false;
if (this.position == this.prev_position)
return false;
Comparing two arrays like this doesn’t work.
You can get the same position in aircraft.json and use it as a “new” position because the object pointer for the array is different.
The other bug was interrupted lines following a dotted segment.
I’m looking at the code but the head_update and tail_update times are just confusing.
I’ve basically rewritten that function in a way that makes sense to my brain.
1 Like
This needs to be projHere instead of projPrev
189 // Keep appending to the existing dashed line; keep every point
190 lastseg.fixed.appendCoordinate(projPrev);
This needs to add projHere in addition to projPrev:
199 // We are back to good data (we got two points close in time), switch back to
200 // solid lines.
201 lastseg = { fixed: new ol.geom.LineString([projPrev]),
should be
201 lastseg = { fixed: new ol.geom.LineString([projPrev, projHere]),
Also i have no idea why there is a separate tail_update and head_update.
It’s completely confusing and unnecessary.
This function in practice appends more points than positions >= 5 seconds apart because tail_update corresponds to when the point before the last point in the segment was added.
235 if (this.last_position_time - lastseg.tail_update >= 5) {
236 // enough time has elapsed; retain the last point and add a new one
237 //console.log(this.icao + " retain last point");
238 lastseg.fixed.appendCoordinate(projHere);
239 lastseg.tail_update = lastseg.head_update;
240 this.history_size ++;
241 }
And finally, adding a new segment every time the altitude changes creates a lot of segments.
Checking that the altitude has changed more than 200 or 400 feet before creating a segment with different color would make sense.
I had made a PR with my changes quite some time ago.
But that included an adjustable history as well and also not adding segments when the lines when the course doesn’t change.
I should have probably separated those things into more than 1 PR.
2 Likes
Ah and you can obviously argue about history loading of tracks should be handled.
But i don’t like how it’s implemented.
When updating normally:
this.updateTrack(receiver_timestamp - last_timestamp + (this.position_from_mlat ? 30 : 5)
plane.updateTrack((now - last) + 1);
Now this tends to produce dotted lines because the 30/5 second grace time isn’t added.
1 Like
Wow i should have just checked my changelog in the pull request.
Anyway wrapping my head around that code was as interesting as it was the first time.
Mostly Webview improvements by wiedehopf · Pull Request #25 · flightaware/dump1090 · GitHub
I guess i could make a new PR with just the bugfixes and altitude logic without the straight line shenanigans.
1 Like
It’s been years since I looked at this code (and I agree it’s pretty nasty) but…
I’m not sure either of these is true. The general invariant is that the current position of the aircraft is not included in the track history (the final line segment - the “elastic band” - is handled when the features are updated)
That code is pretty murky, but IIRC they mean different things? One is the time of the last position, one is the time of the last position stored in the track segment. Something like that.
Anyway, thanks for taking a look at it. All that code was a gradual evolution and I really really don’t like Javascript which is part of the reason why it’s so horrible.
1 Like
No that’s not how it actually works, the current position is added when the newest position in the track history is older than 5 seconds.
(that’s how it’s meant to work, currently more positions are added due to head/tail confusion)
Here the current position is added to the track history (current dump1090-fa code)
232 // Add more data to the existing track.
233 // We only retain some historical points, at 5+ second intervals,
234 // plus the most recent point
235 if (this.last_position_time - lastseg.tail_update >= 5) {
236 // enough time has elapsed; retain the last point and add a new one
237 //console.log(this.icao + " retain last point");
238 lastseg.fixed.appendCoordinate(projHere);
239 lastseg.tail_update = lastseg.head_update;
240 this.history_size ++;
241 }
242
243 lastseg.head_update = this.last_position_time;
There is another inconsistency right in that part, the current point is added but tail_update is set to head_update instead of being set to last_position_time, which corresponds to the point added.
238 lastseg.fixed.appendCoordinate(projHere);
239 lastseg.tail_update = lastseg.head_update;
head_update should be called prev_position_time and saved with the plane object, not the track, as it’s not necessarily included in the track history.
(to be used to know when the position has become stale)
This would reduce confusion greatly what it is.
And i’d probably then rename tail_update to update_time to signify the timestamp of the position most recently added to the track history.
And changing what i proposed fixes the gaps in the track (seen in the screenshot).
I’ll make another pull request focusing on the problems in that function only.
Maybe you can test it and pull it yourself? 
1 Like
Uh, look at around dump1090/public_html/planeObject.js at master · flightaware/dump1090 · GitHub for what I mean. Most of the time, the current aircraft position is not part of the track history. Every 5 seconds or so, it does get added and briefly the current position and the end of the track history are coincident, but that’s something of the exception.
I handed off maintenance of this to the web team specifically because javascript & web stuff is not my area of expertise - I can kinda make something work, but it’s going to be pretty horrible.
1 Like
Well but it’s added to the end of the track history.
(to be more precise projHere corresponding to the timestamp this.last_position_time is added to the track)
Whenever a new line segment is started, the previous and the current positions are added to the track.
this.track_linesegs.push({ fixed: new ol.geom.LineString([projPrev, projHere]),
When the most recent point in the track history is older than 5 seconds, the curent position is added:
lastseg.fixed.appendCoordinate(projHere);
Now when appending estimated track, for some reason projPrev is added, that’s one of the problems.
Well i was asking only because it’s a bug fix.
Not talking about a UI redesign here
I’ll keep the PR minimal and maybe you can shortcut the process.
But it’s fine, i wasn’t expecting a fix for that problem on the screenshot any time soon.
1 Like
I think you might be right for the estimated case. (I’m not entirely convinced - I haven’t walked through it all, but I suspect that a simpler fix is to fix the estimated → not estimated case to fix the final point of the estimated segment before moving on)
In the second case (when we are switching from estimated to not-estimated) we have a pair of positions that are close in time, projPrev and projHere, less than 5s apart. To get that correct, we want the new segment to be the (degenerate, single point) segment containing only projPrev. The elastic feature will then draw a solid line from projPrev to the current aircraft position, which is initially projHere, but will then change as more positions arrive. Eventually, we receive a position that is more than 5s after projPrev; only at that point do we want to add a second point to the non-estimated line segment. So creating the initial line segment with both projPrev and projHere does not look correct; we might want that first line segment to use a later position, not projHere.
There are some corner cases to be careful of here, e.g. when we have a long gap followed by two positions close together followed by another long gap.
1 Like
You are correct.
Just thought about the intention of the code.
I’ll stare at it some more
Ah yes, we can finish the dotted line when transitioning back to good line by adding projPrev to the previous segment.
if (lastseg.estimated) {
// We are back to good data (we got two points close in time), switch back to
// solid lines.
lastseg.fixed.appendCoordinate(projPrev);
lastseg = { fixed: new ol.geom.LineString([projPrev]),
That should keep the intention of the code intact while fixing the problem.
When transitioning from one line type to the next, one point always needs to be added to both line segments.
Doing it like that creates other complications.
Well what i did at least looked like i fixed the problem 
1 Like
This PR is smaller than the last one. I tried to follow the intended logic of the updateTrack function :).
SkyView: Fix aircraft trail handling by wiedehopf · Pull Request #48 · flightaware/dump1090 · GitHub
Do these changes make more sense to you than what i proposed in the previous posts here?
1 Like