Skip to main content
Question

Fast way to get raster from DGN (v8)

  • 25 February 2013
  • 3 replies
  • 5 views

Hi, my problem is that simple dgn->imageraterizer->geotiff is very slow .picture is big 10kmx10km with 0.13cell size (0.13995 m/pxl?)  82500x85000 pixels. Is there any way to get it faster than 3days and counting?

My target is to get 0.13399 m/pxl tiff out from it

Remove any content you don't need from the DGN, such as feature geometries that are unnecessary or attributes that are not required for the rasterization process... (AttributeKeeper / Remover and GeometryFilter / Tester).

 

 

 

Consider Tiling your DGN first and assigning a TileName to each area, you can do this with an arbitrary grid or the Tiler transformer. Once done use the ImageRasterizer to rasterize each tile with the correct size specification but ensure that you set the "Parallel Processing Level" to say 'Moderate' this will allow you to use multiple threads and rasterize several tiles concurrently.

 

 

 

http://fmepedia.safe.com/articles/Samples_and_Demos/Parallel-Processing

 

 

Then if you need just 1 image at the end use the RasterMosaicker to stick the tiles back together.

 


82500x85000 pixels

 

 

That's very big. If my maths is correct, that's 6,806,250,000 pixels

 

Each pixel is probably 8-bits and a color image will have 3 bands.

 

 

That's 6,806,250,000 x 8 x 3 = 163,350,000,000 bits.

 

 

There are 8,388,608 bits in a megabyte:

 

163,350,000,000 / 8,388,608 = 19,472mb (more or less 20gb)

 

 

That's how much data is being processed here. Amazing eh? I bet the DGN dataset is nothing like that size.

 

 

Anyway, if you don't have at least that much memory then FME is going to have to start caching to disk, and that will be slow. A solid-state hard drive would help. So maxing your system specification will help a great deal.

 

 

Incidentally, the output file, while it will be compressed, will be probably 10gb or larger in size. Is that going to work for you?

 

 

I agree with Dave that tiling is probably a good option. My instinct is to tile the data in one workspace and send each tile to another where it would be compressed separately (use the WorkspaceRunner transformer to do that); but now that I'm thinking about it I'm not sure there would be a heck of a difference between our methods.

 

 

Anyway, if you did a 10x10 set of tiles, each tile would only be 194mb of data. FME could handle all that at one time without caching to disk, so the while thing would run quicker than trying to handle it all at once.
...and depending on how you do this, if you want to force FME to cache your data to disk and take features our of memory after one large process and prior to another, then the RasterCheckpointer is a useful transformer to be aware of.

Reply