Scale parameter in geemap.ee_to_numpy

[nguardo24]

Hi, I was trying to run the VegetationLine.extract_veglines but it encountered an error related to geemap.ee_to_numpy function in the Image_Processing.py module (line 523) -> TypeError: ee_to_numpy() got an unexpected keyword argument 'scale'.

I read the geemap documentation related to ee_to_numpy() and the parameter is set to None but you can pass it.

If you have any idea about it, I would appreciate it.

Thanks!

[fmemuir]

Thanks for highlighting this; a recent update of geemap meant the scale parameter is now required, to ensure the numpy array generated has the correct pixel size for your region (the number of rows and columns should match the region length and height divided by the pixel size of the satellite image). This was a recent error that came up for me so I fixed it with the scale parameter (commit here), but it may not be reflected in older versions of geemap. I am currently running v0.30.4. Please try updating/rebuilding your conda environment with a newer version and see if that fixes it!

[nguardo24]

Hi, thanks for your response. I set up a new conda environment (named coastguard2) and I downloaded the repo as a ZIP file, in order to run the software with the new updates (and to assess them). I have installed geemap v0.31 and I'm not receiving the error I mention above but now I encounter the following:

I noticed that for the new version you have to install the arosics library and now I'm receiving an error related to that. Can you guide me on how I can solve that?

Thank you very much!

[fmemuir]

Apologies, the AROSICS coregistering is a recent addition to the features and I forgot to add variables for it to the driver templates. I've amended this now (see commit here), but essentially if you want to use coregistering to align satellite images to one another, you should provide a filepath to a reference image somewhere in the driver file. For example, one of the RGB images that are generated by the tool for your site would work: settings['reference_coreg_im'] = '/COASTGUARD/Data/EXAMPLESITE/jpg_files/20150817T113146_20150817T113145_T30VWH_RGB.tif') If you don't want any coregistering, set that parameter to None: settings['reference_coreg_im'] = None

Hope this helps!

[nguardo24]

Hi Freya, thanks a lot for your response.

I set the settings['reference_coreg_im'] = None and the problem related to AROSICS is solved.

Now, there's another issue related with the processing of LANDSAT images, that happened to me in previous versions of the software. The error is the following:

I did a little debugging of the code and apparently it is passing an empty array to calculate the thresholds related to vegetation. As the array is empty, it can't calculate the np.percentile.

Thanks again and we keep in touch!

[fmemuir]

Hi, could you please post here screenshots of the RGB and classified Landsat 8 images that get saved before that point? It might explain why the array with pixels classed as veg is empty. Thanks!

[nguardo24]

Hi, here are the screenshots:

Classified

NDVI

RGB

[fmemuir]

Thanks for the screenshots - while the RGB image looks a little problematic in terms of the colour channels and saturation of the image, clearly vegetation pixels are still being identified by the classifier. How large is your buffer zone around your reference shoreline? I ask because the int_veg_clip variable that gets read in represents the classified vegetation pixels only within the coastal buffer, and with cloudy pixels masked. If it is very narrow and/or covered by clouds, it may be that there are no pixels classed as vegetation within the buffer zone to generate a transition zone raster from.

[nguardo24]

Hi @fmemuir, thanks for your response.

I understand that buffer zone around the reference line references to the variable named max_dist_ref but correct me if I'm wrong. In that case, it is set to a value of 150 meters.

Should I increase the value of the variable in order to be able to process Landsat images?

Thank you again and I look forward to hearing from you.

[nguardo24]

Hi @fmemuir, I hope you are doing fine.

I have been reviewing the processing using Landsat and I think I found what was happening. Although I sent you the screenshots, in that moment I did not check something that I think results interesting.

As the process was able to create and save the RGB, NDVI and CLASS TIF files before it failed, I loaded them into a QGis project and noticed that they were located in a wrong area. In that sense, the region of interest that I am using is located in the south hemisphere and, for that reason, I assigned the value 32721 to the projection_epsg and image_epsg variables. This value references to the WGS 84 / UTM zone 21S Coordinate Reference System (EPSG 32721).

Landsat images, in general, are georeferenced in the proyected WGS 84 / UTM system referencing to the North Zone, even for south hemisphere. Taking this into acount, I changed the values of projection_epsg and image_epsg to 32621 and the process was successful.

[fmemuir]

HI @nguardo24, thanks very much for following up - that makes a lot of sense! The coastal buffer will be in whatever coordinate projection system you've provided at the start of the driver file, but if the images themselves are in a different projection system then it won't find any rasters to clip before running the transition zone functions. Although that is a weird result, that even for southern hemisphere locations the UTM zones Landsat provides are always northern. I believe this might have been the reason behind similar errors I was getting for a test run in southern Indonesia!

I'll make a note of that in the documentation for anyone else facing this, and close this issue thread if you're happy to proceed!