Skip to main content
  • EN

We have a large number of JPG images that cover the same area (flown with a drone in a criss-cross pattern). We need to split the set of images into smaller, workable groups. The idea is to, if possible, create an area of 2 rows by 2 columns that cover the same area where the images were taken. If an image falls within one of the four quadrants, it should be moved to a specific folder that representsthat quadrant. That way we can correctly subdivide the set of images into four, more manageable blocks.

 

The 2DGridAccumulator seems to be able to setup a grid, but is there now a way to compare each image to each cell of such a generated grid and then move that image to a folder as explained above? As the drone flew in a criss-cross pattern, the date modified for each file cannot be used to determine in what block it should be placed (ie by just using Windows File Explorer to categorise the images).

 

Apologies if there is a straight forward solution for this which I could not find.

Hi @fbinneman​,

Yes, this is definitely possible and there are a few ways you could tackle it. One way would be with the SpatialRelator and a FileCopy Writer with a Fanout.

You can certainly use a 2DGridAccumulator to make the grid but if your tiles are not exact you may find some images may overlap 2 areas; to help with that, you can use a CenterPointReplacer to find which quadrant the image has the most coverage in.

Another consideration with this approach would be to make sure you are copying over both the image and any sidecar files that may be associated with it (this is why I have 2 AttributeManagers before the FileCopy writer). You can use this to either copy or move files but for the sake of this example I used copy.

imageThe file copy writer is pretty straight forward. You define the destination filename and source dataset (which is a format attribute called fme_dataset which you can expose in the reader feature type) and it will place those files in whatever folder structure you have defined in the subfolder name parameter of the writer feature type (using fanout to create a sub directory for each column and row in this example).

2022-06-17_16-41-19Hope that helps.

Hi @fbinneman​,

Yes, this is definitely possible and there are a few ways you could tackle it. One way would be with the SpatialRelator and a FileCopy Writer with a Fanout.

You can certainly use a 2DGridAccumulator to make the grid but if your tiles are not exact you may find some images may overlap 2 areas; to help with that, you can use a CenterPointReplacer to find which quadrant the image has the most coverage in.

Another consideration with this approach would be to make sure you are copying over both the image and any sidecar files that may be associated with it (this is why I have 2 AttributeManagers before the FileCopy writer). You can use this to either copy or move files but for the sake of this example I used copy.

imageThe file copy writer is pretty straight forward. You define the destination filename and source dataset (which is a format attribute called fme_dataset which you can expose in the reader feature type) and it will place those files in whatever folder structure you have defined in the subfolder name parameter of the writer feature type (using fanout to create a sub directory for each column and row in this example).

2022-06-17_16-41-19Hope that helps.

Hi @chrisatsafe​ 

Thank you so much for your detailed answer, as well as the attached workbench. That helped me to understand what to do.

 

Our JPG files worked a bit different than in your example. It does not come with WLD files, but instead uses the EXIF data inside each JPG file to reference it. I had to amend your workbench a bit, but eventually got it to work on our data. In case there is someone who needs a solution working on EXIF data, they can use the workbench that I attach here.

 

Thanks again, my problem is solved!

Hi @chrisatsafe​ 

Thank you so much for your detailed answer, as well as the attached workbench. That helped me to understand what to do.

 

Our JPG files worked a bit different than in your example. It does not come with WLD files, but instead uses the EXIF data inside each JPG file to reference it. I had to amend your workbench a bit, but eventually got it to work on our data. In case there is someone who needs a solution working on EXIF data, they can use the workbench that I attach here.

 

Thanks again, my problem is solved!

Hi @fbinneman​ ,

Fantastic! Thanks for letting me know and for sharing what worked for you!

Reply


Community Stats

30,092
Posts
114,244
Replies
37,717
Members
Terms & ConditionsCookie 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.