Doubts about no data value. Pollination Model


I am working with the Pollination Model and I have some doubts about no data value. Initially, the model has stopped with this error:

“The following 1 raster values [-3.4e + 38] from “lulc_cerrado.tif” do not have corresponding entries in the “value_map”…”

I understood that the LULC raster has the value -3.4e + 38, but the biophysical table does not have it. So, I tried to include the value in the biophysical table, but the error continued.

After some tests, I figured out that the model was not recognizing properly no data values. I reclassified the LULC raster and replaced no data values by “0”. I also added “0” in the biophysical table (with “0” for all variables/columns). It seems that the model ran successfully; however, I would like to know if this strategy is the best one to deal with this issue. Could this strategy (replace no data value by “0”) influence the outputs? Does it make the processing time longer?

I am working with a LULC raster of 7,431,782,400 cells (including no data or “0” cells). I cropped a portion of the raster to test (14,149,380 cells) and the models spent 5 hours. So, if I use the complete LULC raster (and “0”) it could take 109 days =/

I am using LULC raster as a “.tif”. Using NAvalue funtion (R software), I see that the value used to write no data values in the original raster is “-Inf” (which I understand that has been read by the InVEST as -3.4e + 38).

Thank you for your guidance.


1 Like

Hi @fmr, good question.

In general, the best way to handle nodata is to be sure that the raster has the nodata value defined in its metadata. Now that you have all the nodata cells assigned to “0”, you could define “0” as the nodata value in the raster’s metadata. You can do that with GIS software, including the R raster package. But you might need to use writeRaster with the NAFlag option in order to define the new nodata value on disk. And it looks like rgdal::GDALinfo('file.tif') is the recommended way to ask what the current nodata value is.

I suppose if a very large portion of your raster is nodata, this might make a noticeable impact on the runtime. But I suspect that you are looking at very long runtimes no matter what, given 7+ billion cells in your LULC raster!

1 Like