Atlas 0.5.0 Build

external: index parent
internal: preamble patches new build directory ... end

Preamble:

2010-12-02: This Atlas update was commenced in XP using MSVC8. Getting the initial build done was relatively minor, and it seems I may have missed 'reporting' some June 2010 'fixes', thus some things seemed repeated.

Also in this build I separated the shared Atlas and Map modules into a static libAtlas,lib, again something I thought about back in June, that they can both link to... But this effects nothing more than the compile and link order in windows, and does nothing to the unix/OS X builds...

Source Changes

Here is a comment about each of the file changes, more or less in the order they appear in the 'diff' file, atlas-0.5.0.diff.txt. Many of these changes have been added under a _MSC_VER or ADD_CHUNK_LIMIT switch, but they are suggested for all ports, thus some/many of the switches could be eliminated if each of the cross-ports agree...

Since I changed directories for this build, from CVS 'projects/msvc' to 'build/msvc' the changes (diff) in the win_src (winsrc) and msvc folders have not been done. Instead there is a single download of these - .atlas-10-msvc.zip - This build set tries to be fully self-contained, that is uses "..\3rdparty" for all 'external' includes (& libs), and splits off common sources into a libAtlas.lib, which makes for better viewing, and handling in MSVC... more notes below

Source code modification notes -

src/Atlas.cxx

1. Set the variable bool showGraphWindow to false - if not, Atlas seemed to hang... this problem is yet to be solved ;=(( ***TBD*** It seems something to do with the mouse focus in windows. If the graph window is overlaying the main window, and the mouse is clicked and dragged on the main window, main goes to 'black', blank widow, and Atlas becomes un-responsive... sometime will exit on 'q', but after a wait for many seconds...


2. Position the Atlas window to 0,0 - If left to default windows placement, its bottom is sometimes below the status bar, so set its initial position to (0,0)...

src\Graphs.cxx

Do not call puDeleteObject(_slider), since this leads to a segfault... still to be investigated... ***TBD***

src\Image.cxx

Place extern "C" around the jpeglib.h - I thought this had been done in the repo, or at least it had been discussed on the board... This fix should find it way into the rep...

src\Map.cxx

1. Force some GL/glut WIN32 DLL library loads... I guess this used to be done perhaps in PLIB, or somewhere, but now there is a need to be explicit in Map... perhaps a better home for this _MSC_VER block could be found than here in this file...


2. New feature: ADD_CHUNK_LIMIT - Add a new feature of allowing user limitation of the mapping done, by the option --chunk=<chunk_name>. The input chunk, of the form [e|w]nnn[n|s]nn, is kept in a vector array, so a whole group can be given. Basically a MAP_CHUNK consists of a SW lat, lon value, as a 10x10 degree block, a structure stored in the vector, vmap_chunk;.

The previous behavior is fully preserved, and that is to scan both the last given --fg-scenery path, and the destination folder, and schedule for consideration EVERY tile found. But that means if you point Map at a FULL scenery 1.0.1 install, it will proceed to process some 32 thousand plus tiles... which could take some 10 HOURS plus to process...

So this option offers the possibility of pointing Map at a complete world scenery install, thirty thousand plus tiles, but only building Maps on a single or multiple 10x10 degree CHUNK basis. So, for example, using a limit of chunks w010n40 e000n40 w010n50 e000n50 would process the central European region, and chunks e140s30 e150s30 e140s40 e150s40 would yield the Maps for most of the southern east coast of Australia, and some outback, excluding Alice Springs, and so on...

In both the 'test' (--test) output, and the actual tile rendering, added a lot of switch code, to decide if the scheduled (found - either in source or destination) tile is to be 'skipped' or output to disk. In simple abstract, the switching becomes -

for (; i != tiles.end(); i++) {
  TileInfo *t = i->second;
  1 - next if NO source found - do not build tiles when no source available!
  2 - next if chunk limits given, AND the tile is not within any of the given limits.
  3 - next if NOT forced, AND tile map folder already exists.
  ELSE render a Map of the tile to disk;
}

Added the informative output of what would be done, if under 'test', or what has been done, if rendering the tiles -

printf("Of total %d, skip-no-src %d, not-in-rng %d, forced %d, no-ovrwrt %d, [to-write|written] %d\n",
    tile_counter, sk_no_src, sk_not_in_range, sk_forced, sk_no_overwrite, mapCount );

Perhaps a later enhancement on this limit-by-chunk feature, would be that a set of chunks could be entered in one command. At present it is quite cumbersome to enter a block for Central Europe by say -
# Map "--chunk=w010n40" "--chunk=e000n40" "--chunk=w010n50" "--chunk=e000n50"
It would be nice to just enter say -
# Map --chunk=w010n40:e000n40:w010n50:e000n50
or maybe as an area, like --area=w010n40:e000n50
but for now --chunk= repeated is fine...


3. Enhancement: During, what can be the long running of map, the output is very minimalist. Have added some timing (in simple integer seconds) for each 'tile' (map set) rendered - written to disk in each of the sizes 10, 9, 8, 6, 4 - If a pre-count of the 'maps' to be written were done, then this additional output could easily estimate the time remaining to complete the task (in rough seconds terms)...

To facilitate this 'time' output, two small services were created, 'commence_tile(char * pname)', and 'end_tile()', to show the progressive output of tiles (to disk)... this could give even more informative...


4. New options: Force, --force, to force an over write of previously existing tiles. As previous, without this option, the default is to skip the writing of a tile if its output directory, 10, 9, 8, ... exists... This new 'force' option allows the freshening of map files, or even over write the map set using a different palette...

For this option, a new void renderMap2(TileInfo *t) was created, which is really a 'copy' of void renderMap(TileInfo *t), except the 'selection' bitmap it set to the full 'desired' set, rather than just those that have not had the 'exists' bit set. I am sure with more thought this 'duplication' of the rendering service could have been avoided, or at least the common part separated into a new service...

And of course BOTH these services use the 'commenced_tile()' and 'end_tile()' timer, information services to start a tile build, and end a tile build respectively... so some timing, and perhaps statistical information, can be show.


5. These two new options, combined under the ADD_CHUNK_LIMIT flag, add to the HELP output, as follows :-

   #ifdef ADD_CHUNK_LIMIT<
    printf(" --chunk=e000n40 Limit mapping to each 'chunk', 10x10 degree blocks.\n");
    printf(" --force Force overwrite of existing images.\n");
   #endif // ADD_CHUNK_LIMIT

6. FIX: Only call Map_Exit_Ext( &fbo, &rbo ); if (renderToFramebuffer), since these were only allocated if renderToFramebuffer, the default, was true... this leads to a segfault otherwise...

src\misc.cxx

FIX: I thought I had sent a fix for this back in June 2010, but maybe I missed it, but in windows a size_t newLen is unsigned, thus comparing it to less than zero will never happen. So changed this to using an 'int' in windows...

And the native windows function vsnprintf_s, used with the _TRUNCATE switch, would do exactly that - truncate the output - which is NOT what is desired, so changed that to the available length minus 1 (for the null terminator)....

src\Notifications.cxx

FIX: Again, back in June 2010, I thought I addressed this, but nothing seems changed in the repo, so again switched out this 'erase' code, at least for windows. I, and another user, still get a core 'dump' on Atlas exit in Ubuntu, and although I have not yet tested it, this notification erase seems the problem...

src\Palette.cxx

To remove a compiler warning, added 'config.h' include to this file.

src\Subbucket.cxx

FIX: Smallest change to support GIT simgear - use _chunk.get_gbs_center();, instead of _chunk.get_gbs_center2(); It would seem this Atlas/Map suite should support the latest SG/FG from the GIT repo.

src\Subbucket.hxx

1. FIX: Again I thought I had fixed this back in June 2010, but maybe I forgot! Just a little change to support an 'unordered_set' through boost...

2. And this leads to changing the hashing from std::tr1::hash<int>()(...) to stdext::hash_value<int>(...).

src\Tiles.cxx

New: To support the chunk limit range checking of a tile, ADD_CHUNK_LIMIT, added the code here to store the tiles lat and lon as soon as it is (a) found in the source directory scans, or (b) in the destination directory scan. The 'sscanf' function used was increased to also return the n-s/e-w indicators, so a world co-ordinate could be formed and store in the tile information class...

That's about it folks... ;=))

top


Other Items

1: New Build Directory

On my previous build I had used a MSVC build path of 'projects\msvc', containing the MSVC build files, and a number of batch files, for setup, and testing..., and the additional window library sources in a subdirectory of that,  'projects\msvc\winsrc'. But for this build I chose to change this... hopefully improving it...

In this build I have switched to a new sub-directory of 'build', which contains ALL the windows additional stuff. So...

'build\msvc' - Contains the MSVC build files, and various batch files...
'build\win_src' - Contains the sources of the additional windows only library.

And to make the Atlas/Map build fully self contained, this is where I add the '3rdparty' stuff -

'build\3rdparty\include'
'build\3rdparty\lib'

This facilitates a single full zip download and build... without any care of 3rd party includes and libraries... an attempt at a fully out-of-the-box build using MSVC...


2: A little nit!

There still seems some 'confusion', or more it is easy to become confused, over the ways and order in which the various 'paths' are given and used. It seems there should be a review of fg-root, fg-scenery, Atlas path, and path to palette file...

While it is ok Map and Atlas use '--atlas=<path>' as the destination/source of the tile maps, of the various sizes, there should be another way to tell them WHERE to look for their 'constant' data - plane and background image, fonts files, and default Palette, if no specific palette given! As I think suggested before, perhaps a new option would be --date=<path>, where they look for 'constants'...

And at the moment, the fg-scenery path is SINGULAR - the last seen on the command line applies - and maybe this is a deliberate choice to only ever have ONE 'scenery' path. But it would seem better if this were a list of paths... and thus search for the 'stg' files in each of this set of scenery paths...

top


index

Testing

Map - a set of maps generated by map, testing and using the new 'chunk' and 'force' options...

EOP - atlas-07a.htm

top


checked by tidy  Valid HTML 4.01 Transitional