When the site is accessed over HTTPS, the browser may display a warning that the connection is "not fully secure" after loading a file. In Firefox it looks like this:

Cause

The map works by downloading tiles from mapquest.com. These tiles are only accessible over insecure HTTP, which triggers a warning in the browser.

In Chrome, the layout does not adjust properly as the window is resized. If the window is shrunk to produce a 1-column layout and then expanded again, the result is a 2-column layout with the graph still underneath the map.

It would be very useful to have an accurate readout of the exact height value of the data point under the mouse cursor. This could be used (for example) to find out whether a flight qualifies for Silver Height.

Users located in the United States have reported that the flight date displayed is one day earlier than the actual date. This bug may be caused by the large difference between local time and UTC.

Example file: http://crosscountry.aero/flight/view/6074

Bug reported by Richard Brisbourne (@brisbori):

I've found a bug in the display of start and finish lines. While looking at igc files for flights in foreign parts I've found the odd one which contains a declaration in which the start and first turning point are identical.

This throws a divide by zero error trying to calculate a line at right angles to a point, and the trace never displays. While making this declaration is a daft thing to do, the only workround is to edit the igc itself- thereby causing it to fail any validity checks, so the user is lumbered.

I thought of a quick and dirty fix, but I thought I'd run it past you in case you can think of anything more elegant- do this in the addTask() function:

try {
    var startline = getLine(coordinates[0], coordinates[1], startLineRadius, lineDrawOptions);
    taskLayers.push(startline);
}
catch(e) {
    alert("Start and TP1 identical");
}

This warns the user something isn't quite right, but goes on and displays the trace without the start line. We'd need to the same thing at the finish.

Alternatives I thought of- checking the two points for equality- but they are both floating points (although it would probably work). Handling the error at the exact point it occurs is possible, but would need more coding.

Reported by @brisbori:

I've found another bug, but it could be someone else's. The attached file from the recent Queensland state championships shows it- load it in any version and look at the barogram.

To see what's happening, just load the IGC file into a text editor and search for "F0158232307160908271948". The surrounding B records show a negative time difference between successive fixes, which of course causes the parsePosition function to move the date on a day. This happens again during the flight.

Rather than think too hard about a fix I've taken a closer look. It looks like a group of six spurious fixes filling in in place of what should be six fixes in normal sequence. Position shown is identical in all the spurious fixes and the recording interval is 1 second, and consistent with where the glider was at the preceding fix, not where it was at the time shown on the iffy fix. I'm sure this is not how an approved logger should behave.

Other points: there are a lot of "V" fixes round there, suggesting the GPS is struggling. The Clearnav manual says it records and saves internally in a binary format so we could be looking at an artefact of the download software.

I've no access to SeeYou, but Tasknav shows the file normally with a gap at where the interpolation takes place. I've looked at other files from the competition (same pilot different days) and they are normal.

Possible actions:

1. (Very easy). Ignore. Non-compliant files aren't our problem and it could be a one-off. Maybe put on the back burner in case it happens again.
2. (Easy). Instead of just checking for a negative time change in the parsePosition function, check for a large negative change. Result will be a sensible looking display, with minor local inaccuracies.
3. (slightly less easy) Identify time going backwards as evidence of a dodgy fix and reject.

This bug is seen with LX flight recorders. The header record looks like this:
ALXVJF8FLIGHT:1
where:

• A means "This is the flight recorder ID",
• LXV means "Manufactured by LX Navigation",
• JF8 is the logger serial number,
• FLIGHT:1 is a comment.

The serial number of the logger is incorrectly displayed as "JF8FLIGHT:1" (with the comment stuck onto the end).

According to the IGC standard:

• The serial number should be exactly three characters. (LX obeys this.)
• Any additional information after the serial number should be preceded by a comma. (LX does not obey this!)
• The additional information is not required to conform to any particular format.

Suggestion from Ian Ashton, sent via email:

If you were to make any changes, I think it could benefit from being able to have a narrower flight trace rather than the “thick” line that appeared on my screen.

The barogram displays a red cross-hair to show the altitude at the currently selected time. Initially this will be equal to the airfield elevation (usually close to zero).

If the width of the browser window is reduced sufficiently, the horizontal line of the cross-hair slides downwards and appears underneath the x axis:

The narrower the window becomes, the further the cross-hair moves.

As soon as the barogram is replotted (when the time slider is moved or the units are changed), the cursor goes back to the correct position.

Reported by Andy Miller via email:

On my iPad, the button brings up a menu with just two options 'Take Photo or Video' and 'Photo Library'. Neither of these seems to lead to my folder with IGC files.

Alistair,
Sorry for using this out of scope, but I just didn't know how to contact you. I love the webbased ICG log viewer. I'm the webmaster for https://SoaringTools.org/ -- would love to host your stuff, add you as a contributor to the site?

My direct email: jmurtari --at-- SoaringTools.org

It would be useful to have some means of relating the time / height on the graph to a position on the map.

At present the altitude units default to metres and the time zone defaults to UTC.

Using the HTML 5 Local Storage API, it should be possible to remember the user's choices for future visits to the site.

On mobile devices, the flight information and task displays appear in a very small font. Also the form controls are tiny, making it difficult to load a file, choose units or move the time slider.

Tested on LG Nexus 4 in both Firefox and Chrome.