Non-intersection error

[badmatitude]

Hi Neil.

I’ve finally got around to playing with the new RIOS (v2.0.0 specifically), and come across an error that I’ve never seen before. I’m trying to mask a dw1-stage image (i.e. one of your old Landsat footprint images) with a vector layer. My setup is this:

inFiles = applier.FilenameAssociations() inFiles.inImg = ‘/scratch/tmp/0j3aicjx/lztmna_p095r072_eall_dw1m5.img’ inFiles.mask = ‘/apollo/projects/rsc/land_use_and_mgmt/crops/landsatSentinel/shapefiles/croppingLandExtent.shp’ outFile = applier.FilenameAssociations() outFile.outImg = ‘results/timeSeries/p095r072/footprint.tif’ otherArgs = applier.OtherInputs() otherArgs.null = 0 controls = applier.ApplierControls() controls.setReferenceImage(inFiles.inImg) controls.setFootprintType(applier.BOUNDS_FROM_REFERENCE) controls.setWindowXsize(256) controls.setWindowYsize(256) controls.setOutputDriverName('GTiff') controls.setCreationOptions(['COMPRESS=DEFLATE', 'TILED=YES', 'INTERLEAVE=BAND', 'BIGTIFF=NO']) controls.setOmitPyramids(True) controls.setCalcStats(True) controls.setStatsIgnore(0) applier.apply(mask, inFiles, outFile, otherArgs, controls = controls)

Function ‘mask’ is written to return 1 in ‘outImg’ where ‘inImg’ and ‘mask’ are non-null, and 0 otherwise. Note that the projection of ‘inImg’ does not equal that of ‘mask’ (EPSG:32755 versus EPSG:3577, respectively).

The error message is:

Traceback (most recent call last): File "/usr/local/bin/footprint", line 8, in sys.exit(run()) ^^^^^ File "/usr/local/lib/python3.11/dist-packages/cropmapper/scripts/footprint.py", line 137, in run maskCaller(lcls, cmdargs.fOut) File "/usr/local/lib/python3.11/dist-packages/cropmapper/scripts/footprint.py", line 68, in maskCaller applier.apply(mask, inFiles, outFile, otherArgs, controls = controls) File "/usr/local/lib/python3.11/dist-packages/rios/applier.py", line 757, in apply rtn = apply_singleCompute(userFunction, infiles, outfiles, ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/local/lib/python3.11/dist-packages/rios/applier.py", line 826, in apply_singleCompute inputs = readBlockAllFiles(infiles, workinggrid, ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/local/lib/python3.11/dist-packages/rios/imagereader.py", line 63, in readBlockAllFiles arr = readBlockOneFile(blockDefn, symbolicName, seqNum, filename, ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/local/lib/python3.11/dist-packages/rios/imagereader.py", line 85, in readBlockOneFile (ds, bandObjList) = openForWorkingGrid(filename, workinggrid, ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/local/lib/python3.11/dist-packages/rios/imagereader.py", line 229, in openForWorkingGrid commonRegion = findCommonRegion(gridList, vectorPixgrid, ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/local/lib/python3.11/dist-packages/rios/pixelgrid.py", line 371, in findCommonRegion newGrid = newGrid.intersection(grid) ^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/local/lib/python3.11/dist-packages/rios/pixelgrid.py", line 159, in intersection raise rioserrors.IntersectionError(msg) rios.rioserrors.IntersectionError: Images don't intersect

Can you diagnose what’s wrong, and how to correct it? Why did the old RIOS not have the same problem? I see from the release notes that reprojecting of a vector is now done after rasterising, but why would that create an error for me?

There is definitely an intersection between the image and vector when I put the two in QGIS (see below). Could it perhaps be some quirk like the extent of the first block in the image not intersecting the vector? (By the way, the projection of the vector is EPSG:4326, not EPSG:3577 as I originally said.)

I attach a zipped-up vector layer for you to play with.

Thanks, Matt. croppingLandExtent.zip

[neilflood]

Thanks @badmatitude

I will have a look, and get back to you.

[badmatitude]

I managed to figure out how to install a local clone into a virtual environment. Inside the virtual environment, inside Python, rios.version showed as '2.0.2', is the change I was looking for. The exemplar code I gave above now produces correct output: The black area is the intersection between the vector layer and the dw1 image.

Interestingly, a new error is now produced: RIOS is unsuccessfully trying to delete a non-empty temporary directory. Do you think this something to worry about, or is it just related to the strange way I'm RIOS, through the virtual environment?

[neilflood]

Thanks @badmatitude

That is both good and bad news. :-) That seems like I have fixed the original problem, so that is great. However, the temp directory thing is a worry. This does not happen for my tests, so this is something weird and new. Could you look inside the temp directory itself, and see what file is in it?

[badmatitude]

That temporary directory is empty. I tried running my example from a different current working directory, in case that was the problem, and got the same error.

[neilflood]

OK, that is weird.

I will put in a bit of a work-around, to prevent it from raising an exception in this condition. I might even make it do a warning message, but not fail so ungracefully.

I don't think this is related to the previous problem, so I think we can say that is fixed.However, I have not seen this error in any other context, so I am a bit puzzled. I will let you know when I have a work-around done.

[gillins]

@badmatitude is this on Windows? I've seen different behaviour there when removing files...

[badmatitude]

No, Linux (running a virtual environment inside a container), but I wonder whether it's something specific to my setup for the testing. Perhaps just create the new version and I'll raise a separate issue if the tmp directory error ever reappears in an operational context?

[gillins]

hmm that is strange....

[neilflood]

OK, thanks. If you are happy with that possibility, I would certainly be happier than having a kludge in there. I just had a go, but I am not all that happy with it, so let's leave it.

I will create that release for the vector fix (should be 2.0.3).

[neilflood]

OK, version 2.0.3 now available.

Closing this, fixed by #94

[rdenham]

Thanks @badmatitude

That is both good and bad news. :-) That seems like I have fixed the original problem, so that is great. However, the temp directory thing is a worry. This does not happen for my tests, so this is something weird and new. Could you look inside the temp directory itself, and see what file is in it?

Sometimes if the panasas file system is under load, there will be a .panfsXXX type file in a directory, which lingers a little bit longer than it takes to try to delete the directory.

I can check to see if that is the problem in this case.

[neilflood]

Thanks @rdenham. That does sound like the right idea. I do recall occasionally running into those .panfs files myself, years ago.

Obviously I can't test this myself without a Panasas system, so if you could do some investigating, that would be great. If it comes up a lot, it will be unusable, so I am quite willing to put in a kludge to get around it, if we can understand exactly what is required. It may be that we need some sort of catch-sleep-retry thing, or it may be that using shutil.rmtree is already more robust and would do the job fine. Let me know what you find.

[gillins]

I wonder if you should try setting controls.setTempdir('/tmp') or some other directory that is not on Panasas and see if the problem goes away.

@neilflood perhaps we should have an environment variable that controls this globally?

[rdenham]

I'll see if @badmatitude can help me get an example that triggers it and investigate. I'd prefer to not have to modify $TMPDIR since /tmp is often small and can fill up and cause problems. In batch jobs it's typically set to somewhere on /scratch/tmp, which is a network filesystem.

But it might be something else entirely, so first step is see why it's having trouble removing a directory.

[rdenham]

I thought it was threading, seems like it's not. I'll redo my test

[rdenham]

Seems like we have trouble creating and deleting temporary directories on panasas. This must be a new problem because I'm sure I've used this sort of code before. Perhaps I've just not used the 'dir' argument and it creates the file in a non-cluster file system.

[neilflood]

Once you pointed out the .panfs files above, that certainly rang a bell for me. I think I must have tripped over it before, but have no recollection of the context. It may have been something very intermittent, so I never got to the bottom of it. However, it would be good to figure it out. I guess RIOS does not actually have to use a subdirectory for those files, I was just trying to be tidy, so that could be another work-around, if nothing else works.

[rdenham]

I guess RIOS does not actually have to use a subdirectory for those files, I was just trying to be tidy,

That seems like a sensible approach, and that pattern of creating a temporary directory to hold temporary files is not uncommon. Seems more like a problem at our end.

I think if we use controls.setTempdir sensibly we can work with this as it is.

[neilflood]

OK, no worries. If you learn anything more definitive, and want to take further action, just open a new Issue on the topic, and I am happy to adapt things if you need.