Hi FME'ers,

This question came through our support queue, I believe, and is related to raster datasets. In particular it helps to explain the behaviour of processing raster data, and how spatial components are stored in a raster file.

Q) A source raster dataset appears flipped vertically, but even after using the Affiner transformer to fix it, the GeoTIFF output is still written out flipped. Inspecting the output with FME it looks correct, but the actual GeoTIFF file still looks incorrect. Has anyone come across this before?

A) Using the Affiner has fixed the spatial components of the data, but some applications (for example, Windows Photo Viewer) will ignore the location information and still display the original data. Let's see why this is...

A raster dataset is usually a single file, but it often contains two components: the actual raster grid of data, and a set of information about the location of the dataset. This screenshot shows the current location (Affine Transform) values:

A transformer (like the Affiner or Rotator) actually changes this location information, but leaves the actual cells untouched. Here I've applied a 45 degree rotation the the data:

You can see that the transform parameters have changed because of that rotation. The cell values, currently, have not. When I write that data (here to GeoTIFF), then the rotation is still only written as a transformation in the location data.

Let's inspect the output from the writer:

The left-hand side (FME) shows the rotated image, but the right-hand side (Windows Photo Viewer) does not. That's because Windows is only showing the data; it isn't applying the location information. That's fair enough, because Windows Photo Viewer is interested only in the image, not the spatial components. A proper raster tool would display the dataset correctly (as FME does).

But let's say I want to force the raster cells to be actually rotated; how would I do that? Well, it's a simple case of applying the rotation using a RasterRotationApplier transformer:

Now the file is written with the actual grid rotated, rather than being recorded in the location data:

You can tell this by a couple of indicators. Firstly the surround of the raster is black, rather than white (although I guess this would depend on if you'd given a color to the nodata value). Secondly, the Affine Transform parameter has reverted back to its original value (i.e. there is no rotation applied to the location data any more, because that rotation has already been applied to the grid).

I think this helps to illustrate how raster datasets work, which is why I nominated this as my question of the week.

In short, most raster formats store transform values and you can generally rely on these being used to visualize the data correctly. For formats that don't store transform values, FME will automatically apply them when writing the data, so you don't need to worry about it there either.

But, for the rare occasion where transform values are not being used, or you have another reason to want to apply them directly, the RasterRotationApplier transformer is the transformer for you to use.

It is suggested that the input raster also contain a nodata value since applying the rotation often has the effect of adding nodata areas around the corners of the rotated raster (as above). These nodata areas will be filled with 0 or black values (as above) in the absence of an input raster nodata value.

Cell values are interpolated in order to rotate the raster; with the choice of Nearest Neighbor, Bilinear, Bicubic, Average 4 or Average 16 interpolation methods. Nearest Neighbor is the fastest but produces the poorest image quality. Bilinear provides a reasonable balance of speed and quality. Bicubic is the slowest but produces the best image quality.

Let's just highlight a few other interesting questions this week:

• The Holiday Hackathon is back!
• The FeatureWriter silently drops features written to a database.
  • Yes, this is sort of true. What happens is that FME sends the feature to the database, and then the database rejects it. Because FME has sent the feature, it is counted as written. I don't know if we can/will do better in the future, but this is behaviour to be aware of for sure.
• Find the last forward slash in a string?
  • I suspect this needs a regular expression - or the LastSectionOfStringRemover transformer from the hub. If the transformer is the answer, then how can we make it easier to find, so that other users are aware of it?

Also of note this week:

• The FME AR app for iOS got a huge update this week.
  • The app now includes support for geolocation, automatic scale, and direction (compass). I haven't tried it myself, but I'll see if I can find time over the weekend and give it a go. I see someone asked on Twitter if it needs FME2019.2. I'm not sure it does. I think it's the app itself that's important, not the version of FME used to create the data (but I'll report back and let you know if that's not the case).
• Also released this week, FME 2019.2.1
  • This update includes a few bug fixes, such as for the StatisticsCalculator cumulative port issue.
• Well done to everyone for beating Dale in this week's quiz.