Divide by zero error if start and turn point 1 are identical

[alistairmgreen]

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.

[alistairmgreen]

I suppose the best thing we can do in this situation is either:

• Use the take-off position as the start and draw the start line there; or
• Use TP1 as the start and TP2 as TP1.

I'm not really sure which way would make more sense.

[brisbori]

On 13/10/15 18:13, Alistair Green wrote:

I suppose the best thing we can do in this situation is either:

• Use the take-off position as the start and draw the start line
  there; or
• Use TP1 as the start and TP2 as TP1.

I'm not really sure which way would make more sense.

—
Reply to this email directly or view it on GitHub
#15 (comment).

I don't think take off position will work. Declared take-off positions
often aren't in the file, and the actual take-off could be just about
any direction from the first declared point.

I must admit my instinct was just to refuse to draw the line but make
sure the track still displays- at the same time telling the user there's
an error. If we aren't happy with that the best I can suggest is to go
through the declared points probably at the end of parsing the file, and
if we find two successive points the same throw one away. This would
also help if two successive turning points are identical- as it is now
that doesn't throw an error, but the sector display is garbage.
Probably best done at the end of the igc parse function- because we've
already converted to floating point using checking for very small
differences.

Seem reasonable?

Regards