Building Atlas in WIN32 with MSVC8


page jumps: preamble prerequisites SimGear version building downloads update end

Preamble - Atlas site ->

2009-01-17: See update fgfs-049.htm

Atlas - The FlightGear mapping utility

A small post on the FlightGear development board reminded me that I have not built Atlas since back in 2005. The Atlas project is made up of four(4) projects, Atlas, Map, MapPS, and GetMap. Below are some sample images generate by the Map component, from FlightGear data :-

Running Map.exe, with a command to get the KSFO area, like :-
> map --fg-root=path\to\FG\data --lat=37.6 --lon=-122.3
produced the first image, and then adding parameters like :-
--enable-airports --enable-navaids --scale=20
produced the second, here both later converted from a png to jpeg format, although map.exe can also directly output jpeg format :-

Image generated from FlightGear data using the Map program from the Atlas project Image generated from FlightGear data using the Map program from the Atlas project

Fantastic stuff ... The cvs instructions for getting the full latest source are as follows, but you should always first check with the Atlas site, as these can change over time -

cvs login
password: <enter>
cvs -z3 co Atlas



An extract from the MSVC8 VCPROJ files of the include directories of map makes the list of prerequisites clear :-

"..\..\zlib-1.2.3"; ..\..\SimGear; "..\..\lpng1225"; "..\..\jpeg-6b"; "..\..\OpenSceneGraph\include"; "..\..\freeglut\include"

Actually OpenSceneGraph is not really a prerequisite, but today some SimGear headers pull in some headers from it, unconditionally, thus it must be there unless you want to mess with the SimGear headers ;=(( See Note 1 below ...

Likewise, the list of library links is very indicative -
sg.lib pui.lib puAux.lib ul.lib fnt.lib net.lib SimGear.lib libpng.lib zlib.lib libjpeg.lib
And the library include paths :-

Thus before commencing building Atlas, you must download and compile Simgear (see Note 1 below), PLIB, freeglut (or alternative), libpng, zlib, and libjpeg ... And of course, to run say the Map component, then you also need at least the FlightGear base scenery data, or the data for the specific area you want to map ... And if you want to compile the GetMap component, to get landsat images, then you also need libcurl, and Wldap32.lib, to do the HTTP communications ...

All the above implies a WORK folder set as follows, and the LINKS to get each of the sources :-

view of the WORK folders
FG data source

Source Link
SimGear (see Note 1 below)

Actually, during this build the 'curl-prev' folder was in another location, so my GetMap.vcproj file reflects that location. But later I dragged it into this group so all items could be together. Of course, the 'data' folder is FlightGear scenery (at least base) data.


SimGear Version

Note 1: SimGear Version: After trying a linux compile, and getting the same error I get in WIN32, I read up more on which SimGear version to use. I am using the very latest cvs development version, which is SimGear OSG, while I should be using :-

12/15/2007 06:53PM    769,214 SimGear-1.0.0.tar.gz

from say, as this is a PLIB version. This problem exhibits itself in MapMaker.cxx, where the PLIB version of SimGear returns a vector<Point3d> from say get_wgs84_nodes() - see simgear/io/sg_binobj.hxx for details - while the later OSG version now returns a vector<SGVec3d>. While these are more or less the same thing, the compiler does NOT see it that way ;=))

Since this seems the only problem with using the latest OSG cvs MAIN HEAD version of SimGear, then my patch is valid, and could/should also be done for the unix/linux build. That would also explain why the OpenSceneGraph includes are also required. I am sure this would not be a requirement if I was using the PLIB version of SimGear.

return up down


Building Atlas

To have early control of some things, I added the following code snippet to the top of many Atlas source files :-

#include "config.h"
#endif // #ifdef HAVE_CONFIG_H

This was added to at least Atlas.cxx, fg_mkdir.cxx, FlightTrack.cxx, GetMap.cxx, Graphs.cxx, LoadPng.cxx, Map.cxx, MapBrowser.cxx, MapMaker.cxx, MapPS.cxx, Output.cxx, OutputPS.cxx, Overlays.cxx, Preferences.cxx, Projection.cxx, Scenery.cxx, Search.cxx, Tile.cxx, TileManager.cxx, and possibly others, In the case of src\fg_mkdir.cxx it is actually just a change from <config.h> to "config.h" ...

This block was also later added to OutputGL.cxx, which, together with LoadPng.cxx, include <jpeglib.h>, so I could define a special ATLAS_JPEG, so that I could exclude a type define of INT32, which is done in jmorecfg.h. Atlas includes the windows system headers, and INT32 is already defined in there, thus there is a conflict, but not in the jpeg-6b source, which does not include the windows headers. I thus amended jmorecfg.h (line 160) to read :-

#if (!defined(XMD_H) && !defined(ATLAS_JPEG)) /* X11/xmd.h correctly defines INT32 */
typedef long INT32;

This is the beauty of this not-required-for-unix config.h! When I came up against a problem, in many cases the 'fix' could be put in this 'config.h' file. Remember it is ONLY to be used for WIN32, thus HAVE_CONFIG_H should be undefined when building in a native unix/linux systems, and probably cygwin also.

But also a number of unix/linux libc only functions were used, thus I added a set of new files to fill in these gaps in WIN32 C libraries - asprintf.cxx, timegm.cxx, strsep.cxx, rint.cxx, getopt.cxx - Their names implies the function they emulate. As an alternative, perhaps these 'hacks' could be put in a separate static library that is added to the link where required, but that is for the future ... Be warned, these kludges have not been fully tested to ensure they yield the same results as the unix/linux library functions ;=((

The rint() function had already been provided, and I just moved it into its own file, so it could be shared with other projects that now required it.

The existing MSVC7 solution files were used, and converted to MSVC8 files, but needed to ADD several files to the appropriate projects, like Search.cxx (& hxx), Graphs.cxx (& hxx), TileManager.cxx, Preferences.cxx and Tile.cxx, and possibly others. It was important to add FREEGLUT_STATIC to the compiler defines, and CURL_STATICLIB to the GetMap project, since in all cases I have used the 'static' form of the external libraries.

Additionally _ALL_ projects, including _ALL_ the external static libraries were compiled using 'Multithreaded DLL', that is /MD, /MDd for Debug configuration. There is real problems with the LINK if there is a mixture of RUNTIME libraries ... this often causes a lot of people a lot of pain ... every source in the link must be meticulously checked!!!

Perhaps one minor maybe 'bug' with map, is that although it creates a glut window, there is no display in it before it exits after writing the map.png output. Maybe there needs to be a screen refresh added somewhere in the code. But it is just a 'vision' thing, and not important since the PNG output is done ...



If you want to patch the current (as of 24 April, 2008) CVS source, then atlas-01-src.txt is a 'unified' diff patch file for this. See Note 1 above, for the patch to MapMake.cxx, and the SimGear version to use. If you want to patch the solutions files, the, which contains atlas-01-sln.txt, a 'unified' diff patch file to do that, but be aware that this patches them to MSVC8 - they were MSVC7.1. And of course you need the 'new' files I have created,, to patch over the missing WIN32 functions ;=))

If you just want to try out the WIN32 executables on your downloaded FlightGear data, then this (md5=106d10d9e5e6c17963572c51e9fdbbde), is the file for you. If you can not handle 'patch', or prefer to make you own diff against a cvs checkout, then that is in - the full modified Atlas source I used. And all links to the various sources can be obtained from here, but they are also given above.

Have much mapping fun in WIN32 ;=)) A great little tool, which also helps one 'understand' FlightGear scenery files.


2011-10-23: Not exactly an update, but I wanted to 'test' this 2008 Map code in Ubuntu (10.04 linux), thus started with the above windows source, but due to the fact that I needed to compile it against relative recent version of SimGear (2.0, 2.4, and 2.5) had to make a considerable number of 'minor' fixes. Below is this full modified linux source, and a diff patch file showing the changes made...

Date Link Size MD5
2011/10/23 320,976 341f0aa3fb3df9ec9dac98a691948b11
2011/10/23 atlas-w2u.patch.txt 14,841 Can be used patch the WIN32 source

Images generated by 2008 code version of Map

In Ubuntu, with default command: --atlas=tmp
w123n37.png 256x256 w122n37.png 256x256
w123n37.png w122n37.png
In Ubuntu, with command: --atlas=tmp --size=1024 --autoscale --enable-airports --enable-navaids
1024x1024 Images - Click image to load full size
w123n37.png shown at 256x256 w122n37.png shown at 256x256
w123n37.png w122n37.png

The images are exactly the same as those generated in WIN32, where I could also try the 'headless' option, where the images are generated in an off screen buffer, with the same GOOD results! Unfortunately was not able to try that option in Ubuntu, where the 'extension' support has been removed from the later versions of SimGear I had to use, although with effort could maybe get it back using the GLEW library.

These images generated using 2008 Map code sharply contrast with the BLOTCHY images generated by 2011 Map code on EXACTLY the same OS, hardware and drivers ;=(). For example - click to load full 1024x1024 image

IMG w123n37.jpg

Now the trick is to discover how the 2011 code can be modified to produce the same clean images produced by the 2008 code, while also expanding it to the same 'square' sizing ;=))


EOF - Atlas-02.doc

checked by tidy  Valid HTML 4.01 Transitional