bartvandewoestyne / oaconvert Goto Github PK

A Windows installer should be created to put the Garmin maps at the right place in the Windows file hierarchy, and add the necessary entries to the Windows registry. Currently, it seems like the two big Open Source players for creating Windows installers are Inno Setup and NSIS. A lot of developers seem to have a slight preference for NSIS because it has more power, but if it's only for a simple installer (copying some files and setting some registry entries) then InnoSetup might be the way to go...

Add the GNU GPL to each source file. I think it's best to have a script that automates this procedure and easily allows us to add or remove a certain licence_template.txt containing the license text. Probably this is something we can create quite easily with sed/awk/bash...

Some comments from Wim:

• Basemap currently must be disabled, otherwise the color is too dark to be useful.
• The difference in color between a TMA and a CTR is not very well visible on a Garmin GPSMAP device. The color for the CTR needs to be more dark.
• Maybe the option 'transparant' must be disabled, which might make the colors more bright...

• Uploading a second map from MapSource to the GPS results in an error.
• According to Wim, this happends only if 1 or more maps with LFAG zones has been selected. The maps WEEK and WEEKEND appear to work without problems.
• Wim wonders whether it has to do with the underscore character in the name, or the name being too long.

One of the design-challenges we're facing, is how we will deal with the fact that we want to transform the input file to different output formats (Polish format, Google Earth KML, readable screen output,...) Thinking ahead, it is probably wise to already setup the code so that it is easy to add more output formats in the future.

I have been skimming through my Go4 Design Patterns book, and although the difference between State and Strategy is not quite clear to me, I think the State pattern is probably the way to go. We could create an OutputWriter that delegates state-specific requests to a KMLState, PolishState or ScreenState object (all three would be subclasses of an OutputState).

Feel free to comment on this suggestion...

We could also output the airspaces as tracks in a GPX file. These GPX files will be easier to upload to a Garmin unit than the Polish file we create. Disadvantage of this approach is that the airspaces will be visible as tracks on the Garmin unit, not as objects on a map.

Some labels of airspaces have special characters which are not shown correctly. For example Liège CTR.

The DA-record implementation for arcs seems to be outputting arcs, but not the correct ones. Probably due to a coordinate (transformation) problem. A good OpenAir file to test this functionality is one_arc.txt (which represents the CTR of Charleroi and actually has two clockwise arcs in it ;-)

Bertrand Fontaine reports: "Il y a un problème au niveau transparence ou priorité de carte. Si je choisis d'afficher City Navigator par exemple, je ne vois plus ta carte. Par contre, quand il n'y a que la tienne, ca a l'air de fonctionner. Il y a normalement un paramètre de transparence et de priorité que tu dois mettre dans ton fichier."

The only thing that is not getting converted yet are the DB-records. The reason for this is that DB-records are specified in an ambiguous way, of the form

V X=<center>
DB <coordinate1>, <coordinate2>

note that this only makes sense if the distance from the center to the two coordinates is equal. We should check on this, and if the distance is not equal, make a decision on what radius to use for the arc. Possible choices are:

• Smallest radius
• Largest radius
• Mean radius
• ...

Considering the fact that we are working with airspaces and paragliding and sailplane pilots should avoid flying into airspaces, I think the safest strategy is to use the largest radius...

Check if the user specifies a file as input argument. If this is not the case, give an error message and show an example of use.

It would be nice if we did not need the cgpsmapper intermediate step and could directly translate an OpenAir file to Garmin IMG format. This will be a tough one... but maybe not impossible, since there is some documentation on Garmin's IMG file format available at http://sourceforge.net/projects/garmin-img/ Probably, the people who developed cgpsmapper can also help us out here.

Completion of Dutch airspace

The outputStream stuff should definitely get cleaned up... We should allow two things: write to a file that got specified with the -o option, and if no file got specified, simply write to the screen.

Currently, we compute the distance between two coordinates using the haversine formula. There exist more precise formulas, based for example on the WGS84 ellipsoid approximation of the earth. See `Direct and inverse solutions of geodesics on the ellipsoid with application of nested equations' by Thaddeus Vincenty (1975). See also the following links:

• http://www.movable-type.co.uk/scripts/latlong-vincenty.html
• http://www.mathworks.com/matlabcentral/fileexchange/5379

If we assume WGS84 (instead of a simple spheroid) for the approximation of the earth, we should use Vincenty's method for calculating distances.

We can probably make the Parser class a Singleton. I can't think of a situation where we would need more than one Parser object... There should be one and only one Parser for parsing the input file.

The code should also compile under Windows, preferable with Open Source tools. Possibilities are to compile under Cygwin, MSYS/MinGW or with an IDE like Eclipse or Dev-C++. My best attempt so far was under Cygwin, where cmake runs fine and all source files get compiled to an object file, but things go wrong at the linking stage... probably something that has to do with the boost libraries not being found... if anybody knows how to fix this, I would be happy to hear!

Use size_type wherever we loop over a vector to be on the safe side and have clean code. See e.g. http://stackoverflow.com/questions/4849678/c-for-loop-size-type-vs-size-t

Add night colors to the Garmin TYP file.

I'm not sure if the label from an AN record in an OpenAir file gets cleanly into the Label for the [POLYGON] in the Polish file. We should check that. Maybe we could also add the airspace class to that string, so that a user can easily see the name and class of the airspace he's flying in.

Find formulas and specs for WGS84 system and/or IERS 2003 spheroids. Probably we'll need them for the Latitude.getM() and Longitude.getN() functions. Let's hardcode WGS84 for now, but in the future, we should allow the user to configure his type of spheroid in a config file.

It seems like the generated arcs for DB records have an incorrect start and/or end angle. My educated guess is that this is NOT due to rounding errors, but somehow a bug in the code. It would be nice if this one is fixed...

Wim suggests the following:

• Restricted: red border
• Danger: orange border

The following changes, effective as of 12 Jan 2012, as described in Belgocontrol AIRAC Nr. 01/2012 still have to be implemented. These changes are a low priority as these zones are not relevant for the paragliding maps.

1. Liège Vectoring Area One
2. TRA SA
3. TRA/TSA S1
4. TRA/TSA S4
5. TRA23

When dealing with an airspace that has a Polygon with no points, the Polygon should not be shown when the airspace is printed to the screen.

Some junk is left -over in the Start Menu after an uninstall in Windows. Probably is related to this issue: http://nsis.sourceforge.net/Shortcuts_removal_fails_on_Windows_Vista See also https://www.bunkus.org/bugzilla/show_bug.cgi?id=305 for example. If somebody can fix this, please go ahead...

To automate the build process, it would be better if we made use of CMake to generate our Makefiles, instead of writing them manually...

The level and zoom settings in the header of the Polish file are tricky. We should find good default settings that give good results on most Garmin units. To test this, I assume one needs to create a Polish file, upload it to a Garmin unit and then see if the result looks good. Conclusion: testing this will probably be quite a trial-and-error process that takes a lot of time. We will need testers for this!

Add an option --max-altitude (or --ceil) with which a user can decide to only select those airspaces which have their lower limit below the given value (in meter or in feet). This way, paragliding pilots can for example decide to not visualize everything above 4500 ft.

Currently, the Point and PolishState classes generate a warning about an unused parameter in a function:

[ 70%] Building CXX object src/CMakeFiles/airspace.dir/Point.cpp.o
/users/vandewoe/Dropbox/MyProjects/oaconvert/src/Point.cpp:40:6: warning: unused parameter ‘resolution’ [-Wunused-parameter]
[ 76%] Building CXX object src/CMakeFiles/airspace.dir/PolishState.cpp.o
/users/vandewoe/Dropbox/MyProjects/oaconvert/src/PolishState.cpp:215:6: warning: unused parameter ‘out’ [-Wunused-parameter]

This should be fixed in a clean and Object-Oriented friendly way.

When dealing with an airspace that has an empty polygon, the polygon should not be shown in the output.

The zoom level above which the element will not be displayed can be read from the OpenAir file.

The 'MapSource Maps Compatibility' v0.2 Beta program reports the error 'TYP: MAP DONT MATCH!' for the WEEK map, and the errors 'TYP: NAME TOO LONG!, MAP DONT MATCH' for the WEEKEND maps.

For now, I visualize the Polish files that my program produces using GPSMapEdit on Windows. Because I'm coding on Linux, i have to reboot for this. It would be nice if I had a tool on Linux to visualize the Polish files that I produce. If somebody knows of such a tool, I would be glad to hear!

There seems to be a conflict in the naming/numbering of airspace zones:
both Belgocontrol and SIA have a zone called "Luxembourg TMA 5" which seems to be different.

We need to check how the software will handle this.

Everytime when I needed the value of pi in my code, i simply created a double const with an approximate value for pi, but of course that should change in the future... I simply was too lazy to figure out what the clean and most standard-confirming way of using the pi-constant was in my program. If any body knows, please go ahead...

Find the formulas for the exact meridional and normal radius of curvature in case of an elliptic model of the earth and implement them in an extra Latitude.getM() and Longitude.getN() so that we start getting closer to WGS84. See http://en.wikipedia.org/wiki/Latitude#Degree_length.

The color for the airspaces in the Polish File can be extracted from the SP and SB lines in the OpenAir file.

We should make things work on Mac: the Garmin IMG maps should be able to load in BaseCamp for Mac, and we should provide instructions on how to install everything for Mac.

To parse the OpenAir commands, we can probably make use of the Boost RegExp library: http://www.boost.org/doc/libs/release/libs/regex

Wim reports that on his Garmin GPSMAP 62, the map 'WEEK' is with colors, but the map 'WEEKEND' is without colors. In MapSource, both maps are with colors.

I tried to implement the State pattern with only PolishState as concrete state, but I wasn't able to make it work. Somehow, the OutputState::write(Airspace) method is called instead of the PolishState:write(Airspace) method. I think we should somehow enforce users not to be able to call any methods from the OutputState class. I thought I had done that by making the OutputState::write(Airspace) virtual, but it seems like it still gets called...

When uploading the two maps 'WEEK' and 'WEEKEND' to a Garmin device, it is only possible to turn on or off 'My Very Special Map', but not 'WEEK' or 'WEEKEND' individually. Wim thinks this has to do with certain numbers that are automatically assigned and which are probably not unique.

Show the map boundary in a thick black line.

It would be nice if we also have KML output so that the 3D airspaces can be visualized in Google Earth. For more info on generating KML files, see http://code.google.com/apis/kml/ and http://www.opengeospatial.org/standards/kml/

To check if we output valid KML, we could use http://www.kmlvalidator.com/home.htm

Once the command-line client is working, we could add a GUI. Coding the GUI should be as cross-platform as possible. I was therefore thinking of using Qt...

It seems like not all spaces get transformed. For example:

$ grep ^AN openair/third_party/lvzc/BELLUX_WEEK_110302.txt  | wc -l
174
$ grep ^Label openair/third_party/lvzc/BELLUX_WEEK_110302.mp  | wc -l
46

So for the BELLUX_WEEK_110302 file, we only have 46 POLYGONs, where there should be 174...

Completion of French airspace.

We'll do it properly and document our code, so we need a documentation system. I assume Doxygen is the preferred and most standard way to go, isn't it? Or are there other valuable players in the market?

We should have a way to compute distance between two coordinates, because we will need this functionality when implementing DB-records for arcs that get specified as follows:

V X=<center>
DB <coordinate1>, <coordinate2>

Notice that this arc is only valid if the distance from the center to both coordinate1 and coordinate2 is equal. To be able to check this, we need to be able to compute distances between coordinates. Probably, the so-called 'Haversine' formula is the way to go.

Interesting links could be:

• http://www.movable-type.co.uk/scripts/latlong.html
• http://mathforum.org/library/drmath/view/51879.html
• http://www.faqs.org/faqs/geography/infosystems-faq/
• http://en.wikipedia.org/wiki/Great-circle_distance
• http://en.wikipedia.org/wiki/Haversine_formula
• http://blog.julien.cayzac.name/2008/10/arc-and-distance-between-two-points-on.html