One of the issues that comes up with doing the map mosaics for NZ Rail Maps is that the resolution of Retrolens aerial imagery can often be very high, when using the official NZR survey images at the scale that they appear on Retrolens. A typical scale is only 1:4300 which gives us a lot of detail on the ground. However to mosaic that over the Linz stuff can be problematic when some of the latter comes in at a much smaller scale. This week I was working with source imagery of 0.5 metres (pretty unusual for Linz aerials from the last five years) and the downscaling of the NZR stuff to match this would result in way too much detail being lost.
So the obvious solution is to go the other way and upscale the Linz stuff but the problem is you end up with a massive tile size that the current version of Qgis can't handle very well. As an example, the railway station at Tokoroa is covered by one single tile at 4800x7200 pixels with each pixel measuring 0.5 metres on each side. This is called 92VJD-92MCL in the EPSG:3857 grid that Linz supply the imagery in. Scaling that up in Gimp to 0.1 metre (500%) gives us a tile that is now 24kx36k pixels which means 25 times in total area and even the smallest export will be over 200 MB which Qgis finds very hard to handle.
So the solution arrived at here was to split the scaled up tile into 25 tiles at the original dimensions. This has all been done by hand this first time, laboriously cutting out the grid sections and pasting them one at a time as individual layers into a new image, but apparently it should be possible to set up some guides in Gimp and use the guillotine tool to automatically slice the original into pieces (hopefully with each piece as a separate layer).
The next step is to come up with a new grid where a set of numbers get added to the original column and row references of the original tile. 92VJD refers to a column name and 92MCL refers to a row name. So I cobbled together a spreadsheet and obtained the top left coordinates from various world files in a table in the sheet so that I could work out the height and width of the original tile and then divide these numbers into fives so that I can work out the top left coordinates to put into our new world files for the new grid. So in accordance with the way I have done it in the past, 92VJD-92MCL will become 92VJDx5.1-92MCLx5.1 and this decipers as, x5 means that we have scaled the original tile up five times, and .1 means this tile is a piece of the full tile. As we have a 5x5 grid of tiles then the column and row numbers range from x5.1 to x5.5. In other words the part that is actually a row or column number is the part after the decimal point.
Then with the spreadsheet, it did the calculations to work out the top left coordinates to put in the copies of the world files that were produced for each new tile, and after a bit of trial and error, it worked just fine. Qgis is now using a much more reasonable amount of memory because it only needs to load five tiles (1/5 of the original tile size) of around 15 MB each instead of the very large original of over 200 MB and the refresh is much faster and Qgis takes much longer to run out of memory. So that has been worthwhile but it took ages to set up so I need to work out ways to speed it up and that guillotine tool, if I can make it work, could speed up the slicing a lot, and a Python script or the like to work out the new coordinates and maybe even write the new world files directly so as to save a lot of manual editing and copying files.
I have a similar thing happening in respect of the map tiles for Waipara where I have simply added new tiles that were not in the original supplied imagery grid because of covering some original areas to the side of the supplied grid and so I have to again calculate manually the correct coordinates for the new tiles. But this case is not one of having scaled the original images and I did not have to create the grid like I did in the example mentioned above. So that one will not be anything like as much work.
UPDATE: For the time being I have created a Gimp template that creates a grid of up to 5x5 4800x7200 layer tiles. When a new mosaic project is created these tiles are in the background and enable the grid numbering system to be followed for exported tiles out of the full image when the full image is cropped to individual tiles. This does not directly address the purpose of scripting which is to auto generate World files for individual tiles that are created out of a full mosaic. The scripting task is still being considered at this stage, meanwhile the World Slice Calculations spreadsheet has been in use to calculate the coordinates of each tile.
UPDATE: For the time being I have created a Gimp template that creates a grid of up to 5x5 4800x7200 layer tiles. When a new mosaic project is created these tiles are in the background and enable the grid numbering system to be followed for exported tiles out of the full image when the full image is cropped to individual tiles. This does not directly address the purpose of scripting which is to auto generate World files for individual tiles that are created out of a full mosaic. The scripting task is still being considered at this stage, meanwhile the World Slice Calculations spreadsheet has been in use to calculate the coordinates of each tile.