.gitignore: Added *.bak files which are generated by texmaker.
Manual en atmosphere and instruments: Refined RASP usage.
Manual de atmosphere and instruments: Added hint to RASP usage.
Topography/XShape: Fix non-OpenGL polygon shape rendering

Fixes trac issue #3245.

The old code rendered polygons having holes using
  "points[0]        ...  points[lines[0]-1],
  "points[0]        ...  points[lines[1]-1], ..
instead of
  "points[0]        ...  points[lines[0]-1],
  "points[lines[0]] ...  points[lines[1]-1], ..

This caused issues for shapes containing holes, e.g. water
areas with islands.
Screen/Memory/RasterCanvas: Fix rendering of clipped polylines

Fixes trac issue #3250.

Given a closed polygon A-B-C-A where A-B requires clipping B to B'
giving a clipped line A-B' it is not valid to then draw the line
B'-C. Instead clipping needs to be performed again on B for the
line B-C giving B'' to render B''-C.
Manual en: Fix reference to devices sync settings
doc/manual: Fix truncated lines

Fixes trac issue #3247.
Topography/XShape: Don't show "UNK" shapes labels

Occurred on many water areas, probably short for "unknown".
Gauge/FlarmTrafficWindow: Always initialize pens, colors and brushes

Silence compiler "may be used uninitialized" warnings by
introduction of a (unused but safe fallback) default case in
switch statement.
Gauge/FlarmTrafficWindow: Always initialize circle_pen

Silence compiler "may be used uninitialized" warnings.
The initialization is not needed (circle_pen is only used if
"circles > 0") so this change causes a slight performance penalty
in the general case.
Gauges/LogoView: Always initialize titlex/titley

Silence compiler "may be used uninitialized" warnings.
MapWindow/GlueMapWindow: Always initialize min_time

Silence compiler "may be used uninitialized" warnings by
introduction of a (unused but safe fallback) default case in
switch statement.
Device/Driver/IMI/Protocol: Explicitly make aliasing visible to compiler

Fixes compilation with strict aliasing rules:

src/Device/Driver/IMI/Protocol/MessageParser.cpp: In function ‘IMI::TMsg& IMI::MessageParser::GetMessage()’:
src/Device/Driver/IMI/Protocol/MessageParser.cpp:66:19: error: dereferencing type-punned pointer will break strict-aliasing rules [-Werror=strict-aliasing]
   return *(TMsg *)buffer;
Device/Driver/WesterboerVW921: Explicitly make aliasing visible to compiler

Fixes compilation with strict aliasing rules:

src/Device/Driver/WesterboerVW921.cpp: In function ‘float ReadFloat(const void*)’:
src/Device/Driver/WesterboerVW921.cpp:176:28: error: dereferencing type-punned pointer will break strict-aliasing rules [-Werror=strict-aliasing]
   return *((float *)&result);
Renderer/TrailRender: Always initialize last_point

Silence compiler "may be used uninitialized" warnings.

This is actually something the compiler should have been able
to identify as not problematic since "last_valid", on which the use
depends, is a local variable and always initialized.

src/Renderer/TrailRenderer.cpp: In member function 'void TrailRenderer::Draw(Canvas&, const TraceComputer&, const WindowProjection&, unsigned int, bool, RasterPoint, const NMEAInfo&, const DerivedInfo&, const TrailSettings&)':
src/Renderer/TrailRenderer.cpp:189:64: error: 'last_point.RasterPoint::y' may be used uninitialized in this function [-Werror=maybe-uninitialized]
             canvas.DrawCircle((pt.x + last_point.x) / 2, (pt.y + last_point.y) / 2,
                                                                ^
src/Renderer/TrailRenderer.cpp:189:37: error: 'last_point.RasterPoint::x' may be used uninitialized in this function [-Werror=maybe-uninitialized]
             canvas.DrawCircle((pt.x + last_point.x) / 2, (pt.y + last_point.y) / 2,
Windows/CE: Fix literal suffix C++11 warnings

src/Terrain/RasterWeather.cpp:396:22: error: invalid suffix on literal; C++11 requires a space between literal and identifier [-Werror=literal-suffix]
     _stprintf(Buffer, _T("%d")_T(DEG), val / 2 - 20);
po: update Polish translation
po: update Ukrainian translation
po: update Spanish translation
Device/Westerboer: ignore implausible values from buggy devices

I have one Westerboer NMEA dump that indicates a true airspeed of
5242.5 kph.  This is clearly outside the limits documented by
Westerboer, and thus must be a bug in the Westerboer firmware.  To
avoid this problem, I hereby apply all limits documented by
Westerboer.