Skip to main content
Solved

Raster Overlapping

  • October 11, 2017
  • 4 replies
  • 218 views
bjudes
Enthusiast
Forum|alt.badge.img+10

I have multiple black and white rasters. I want to mosaic them together and then compress them to make them more manageable. These rasters however are scanned images of historic mapping.This means that I have areas outside the georeferenced bounding box that are white(see image). Most sheets have these white areas, so when I mosaic these sheets together there is overlapping, this leads to part of a sheet being covered by another sheet.

As these sheets are georeferenced should the extra white areas not both be forced underneath the sheets they overlap? Is there anyway I can force this to happen?

Best answer by fmelizard

Hi @bjudes

 

 

The RasterMosaiker (as of FME 2017) has some new options which can control which pixel values take precedent when images are overlapping. By default FME will just order them by the order that they reach the RasterMosaiker (Last) but you can change this to be 'Minimum' (or maximum) depending on the pixel value. There may be a bug here but this is fixed in the latest version of the FME 2018 beta if you find it's not giving you what you expect.

 

 

You will still get the black lines at the corners unfortunately so as @nmatton has suggested clipping might still be your best bet.

 

 

The other option (a bit more complicated) is to turn the white pixels into NoData. The NoData pixels will be ignored - This works best with a single band image (Numeric raster). Try the RasterBandNodataSetter and use the pixel value of the while pixels to set to NoData. If instead you have three bands (RGB) then you might want to consider adding and alpha (transparency band). You can use the RasterInterpretationCoercer to go to RGBA. (Here's a bit more information if you want to go down that route)

 

 

To make these images smaller in file size I would suggest that the output raster only has a single band (with white pixels as NoData). As @gio has suggested this will also make it easier to process. Typical color images have three (or four) bands - RGB (or RGBA) each band adds more data increasing the file size.
View original
Did this help you find an answer to your question?

4 replies

gio
Contributor
Forum|alt.badge.img+15
  • gioContributor
  • Contributor
  • October 11, 2017

Sounds like you need to do some RasterExpression evaluation. (merge the rasters)

Being black (or greyscale) and white makes it easy.

nmatton
Contributor
Forum|alt.badge.img+4
  • nmattonContributor
  • Contributor
  • October 11, 2017

If you have the exact bounding box for each tiles, you can use the Clipper with a corresponding attribute between the bounding box and its raster tile that you put in the Group By option.

Then use the RasterMosaicker to create your mosaic.

Finally, use the geotiff writer with lzw compression

fmelizard
Safer
Forum|alt.badge.img+18
  • fmelizardSafer
  • Safer
  • Best Answer
  • October 12, 2017

Hi @bjudes

 

 

The RasterMosaiker (as of FME 2017) has some new options which can control which pixel values take precedent when images are overlapping. By default FME will just order them by the order that they reach the RasterMosaiker (Last) but you can change this to be 'Minimum' (or maximum) depending on the pixel value. There may be a bug here but this is fixed in the latest version of the FME 2018 beta if you find it's not giving you what you expect.

 

 

You will still get the black lines at the corners unfortunately so as @nmatton has suggested clipping might still be your best bet.

 

 

The other option (a bit more complicated) is to turn the white pixels into NoData. The NoData pixels will be ignored - This works best with a single band image (Numeric raster). Try the RasterBandNodataSetter and use the pixel value of the while pixels to set to NoData. If instead you have three bands (RGB) then you might want to consider adding and alpha (transparency band). You can use the RasterInterpretationCoercer to go to RGBA. (Here's a bit more information if you want to go down that route)

 

 

To make these images smaller in file size I would suggest that the output raster only has a single band (with white pixels as NoData). As @gio has suggested this will also make it easier to process. Typical color images have three (or four) bands - RGB (or RGBA) each band adds more data increasing the file size.
bjudes
Enthusiast
Forum|alt.badge.img+10
  • bjudesEnthusiast
  • Author
  • Enthusiast
  • October 17, 2017
fmelizard wrote:

Hi @bjudes

 

 

The RasterMosaiker (as of FME 2017) has some new options which can control which pixel values take precedent when images are overlapping. By default FME will just order them by the order that they reach the RasterMosaiker (Last) but you can change this to be 'Minimum' (or maximum) depending on the pixel value. There may be a bug here but this is fixed in the latest version of the FME 2018 beta if you find it's not giving you what you expect.

 

 

You will still get the black lines at the corners unfortunately so as @nmatton has suggested clipping might still be your best bet.

 

 

The other option (a bit more complicated) is to turn the white pixels into NoData. The NoData pixels will be ignored - This works best with a single band image (Numeric raster). Try the RasterBandNodataSetter and use the pixel value of the while pixels to set to NoData. If instead you have three bands (RGB) then you might want to consider adding and alpha (transparency band). You can use the RasterInterpretationCoercer to go to RGBA. (Here's a bit more information if you want to go down that route)

 

 

To make these images smaller in file size I would suggest that the output raster only has a single band (with white pixels as NoData). As @gio has suggested this will also make it easier to process. Typical color images have three (or four) bands - RGB (or RGBA) each band adds more data increasing the file size.
I tried a little of all the suggestions, but in the end setting the Overlapping Values to "Minimum" seems to have done the job.

 

 

Thanks very much everyone for the help.

 

Reply


Helpful Members This Week

Community Stats

31,199
Posts
118,262
Replies
38,802
Members

Latest FME

Terms & ConditionsCookie settings

Cookie policy

We use cookies to enhance and personalize your experience. If you accept you agree to our full cookie policy. Learn more about our cookies.

 
Cookie settings
A product of
Safe Software respectfully acknowledges that we live, learn and work on the traditional and unceded territories of the Kwantlen, Katzie, and Semiahmoo First Nations.