Talk:Warp-gbos

To get this working on Ubuntu lucid, I had to do the normal steps, including the workaround of editing /usr/includes/xmorph/warp.h and commenting out the braindead_mcv.h reference, but also: editing the makefile to point to perl 5.10.1 instead of 5.10.0 and installing libboost-dev-all (not quite sure which one was needed for Boost::ProgramOptions so installed them all!

Hope that helps someone

Just a quick heads up, I ported warp-gbos 0.5 successfully to Mac OSX 10.6 some time back and it runs quite happily, but version 0.6 crashes as soon as it generates any tiles. The relevant stack trace is :

Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_INVALID_ADDRESS at address: 0x0000000000000010 [Switching to process 37383] 0x000000010046cbbc in gomp_resolve_num_threads () (gdb) bt

1. 0 0x000000010046cbbc in gomp_resolve_num_threads ()
2. 1 0x00000001002f3aa5 in AcquirePixelCache ()
3. 2 0x00000001003a8a57 in AcquireImage ()
4. 3 0x000000010031e2eb in ConstituteImage ()
5. 4 0x0000000100245da4 in MagickConstituteImage ()
6. 5 0x0000000100026893 in ImgMagick::Save (this=0x106680da0, filename=0x106520ae8 "out/12/2006/1290.jpg") at ImgMagick.cpp:72
7. 6 0x0000000100004528 in TileJob::Render (this=0x10652e8e0) at GenTiles.cpp:412
8. 7 0x000000010001ed46 in TileJob::operator() (this=0x10652e8e0) at GenTiles.cpp:230
9. 8 0x000000010001ee42 in boost::detail::thread_data<TileJob>::run (this=0x10652e780) at thread.hpp:61
10. 9 0x0000000100cfa254 in thread_proxy ()
11. 10 0x0000000100a69456 in _pthread_start ()
12. 11 0x0000000100a69309 in thread_start ()

Hope that's of some use. I might see what other threading options are available. --Ritchie333 23:58, 29 September 2010 (BST)

(Edit: It looks like the same problem as this : http://studio.imagemagick.org/discourse-server/viewtopic.php?f=1&t=15994&start=0 . I'll try rebuilding ImageMagick without OMP support and see if that fixes it)

Thanks for the info. I think there is a crash bug in gentiles, and I have not had time to isolate it (I suspect the way tiles are loaded using time stamps can be unsafe in some cases). From the stack above, this looks like a separate problem. --TimSC 11:50, 30 September 2010 (BST)

I haven't had a chance to look at the new code in depth, but I can think of a number of pitfalls. What happens if thread 1 is still doing Lowestoft on zoom 11, and thread 2 then starts doing South Harris on zoom 12, but there's not enough space to keep all the relevant map images in memory at once?

I'd quite like to put in a compile flag to turn threading off (or make passing -threads 1 do the same thing), as the Mac Pro I've borrowed from work flies through tiles (doing all of England and Wales half inch from zooms 5 - 13 in under 7 hours, compared to 29 hours on my regular Linux box).

I'm actually in the process of making a 0.7 (ish) release of gentiles which merges in the changes I did to allow tiles to split by a variety of alternative projections (notably WGS84 lat / lng). in the same bounds file, so I might see if I can pop this in at the same time. --Ritchie333 14:40, 30 September 2010 (BST)

The variable tilesLoadable is set if the tiles will fit into memory all at once (and activates multi-threading). Multi-threading is only activated if all the tiles can fit in memory. If you want to disable multi-threading, force tilesLoadable to be zero (this could be done by a compile flag as you suggested). --TimSC 16:10, 30 September 2010 (BST)