I have this error log from running the SDR model.
" File “Z:\opt\atlassian\pipelines\agent\build\env\lib\site-packages\pygeoprocessing\geoprocessing.py”, line 3125, in merge_bounding_box_list
ValueError: Bounding boxes do not intersect. Base list: [[8.692083333333333, 9.352083333333333, 8.99513888888889, 9.918472222222224], [7.999599999999999, 7.999599999999999, 10.0004, 11.0004], [407760.0, 985470.0, 533880.0, 1126710.0], [8.1667, 8.9167, 9.3083, 10.191700000000003], [8.1594, 8.9152, 9.308600000000002, 10.192200000000001]] mode: intersection result: [407760.0, 985470.0, 8.99513888888889, 9.918472222222224]
2019-06-10 10:15:42,808 execution.run(83) INFO Execution finished"
InVEST-Sediment-Delivery-Ratio-Model-(SDR)-log-2019-06-10–10_15_41.txt (3.7 KB)
Hello @asbusari -
Have you searched this forum for “bounding box”? There are several threads on this issue, so see if any of the recommendations there help. If they don’t help, let us know what you tried and we’ll help figure it out.
my input datasets are all in the same projection system. I have no clue why this problem persists, yet I have searched all of this forum for solution
I have also attached the database file and the SDR log.
Kindly, provide support as much as possible.
I am glad.
InVEST-Sediment-Delivery-Ratio-Model-(SDR)-log-2019-06-10–20_31_20.txt (3.7 KB)
(Attachment taskgraph_data.db is missing)
Thanks for posting the log file. The ValueError says this:
ValueError: Bounding boxes do not intersect. Base list: [[8.692083333333333, 9.352083333333333, 8.99513888888889, 9.918472222222224], [7.999599999999999, 7.999599999999999, 10.0004, 11.0004], ***[407760.0, 985470.0, 533880.0, 1126710.0]***, [8.1667, 8.9167, 9.3083, 10.191700000000003], [8.1594, 8.9152, 9.308600000000002, 10.192200000000001]] mode: intersection result: [407760.0, 985470.0, 8.99513888888889, 9.918472222222224]
I have highlighted the bounding box values that are much different than the rest (hm, bold doesn’t seem to show up - the values are [407760.0, 985470.0, 533880.0, 1126710.0]). Look at each of your layers and see if any of have this extent. If so, this is the layer that the model thinks has a different coordinate system than the rest, so look closely to make sure that it matches the others exactly.
I have looked at the layer which has that particular extent. It has the same projection and I even overwrited it over again. In spite of that, the same error persists. That layer you highlighted is the LULC raster (GDAL supported) layer (with integer LULC codes for each cell) & it is expected to have a larger extent!
Do you have a clue into what could possibly be wrong?
In the HQM which requires inputting multiple LULC layers; I used 3 LULC layers among which the layer’s whose extent is complained about now in the SDRM was used without errors. Although, it took about 11 hours for that particular HQM to successfully complete over the weekend. If the extent was so misfit, I expect this kind of error log to have been suggested by the HQM. Or what do you think, please?
I just found out that it does not matter what CRS your individual layers have to successfully run the SDR model. I tried all manner of approaches to bring my layer (sourced from different databases) to align, but they did not until I put the non-aligning layers into their default CRS. Then, the model ran successfully BUT THE RESULTING VALUES WERE EXTREMEMLY LOW. Can anyone look into this with me please?
Hi @asbusari -
I’m glad to hear you got SDR to run. Can you explain more what you mean by “their default CRS”? It is necessary that all of the spatial layers be in the same coordinate system, and the coordinate system must be projected (in meters, like UTM), not geographic (in degrees, like WGS84.) Which coordinate system do your layers have, now that they run?
Also, when you say “extremely low”, can you give an example? We just had another thread where someone reported extremely low values, I said to make sure they have a projected coordinate system, and that the units are correct for each input layer, and that solved their problem.
the data were crosschecked over again. Now, everything worked with acceptable values!
Thank you for your support.