Problems with the new Recreation: "Please reduce the extent of the AOI"

Software Support
1

I am running the recreational package for the city of Rio de Janeiro, Brazil, only for the year 2017, with no regression/covariates included, just as a test. Apparently, the AOI is too big because there are > 40 million Twitter points; flicker is ok (see log below). Rio de Janeiro has 1.200 km². Is that really too big? Is there any way around that?

Thanks,

Mariana

Here is the log:

2026-09-15 19:07:52 natcap.invest.utils Level 100 Writing log messages to [C:\InVEST\Meridien_recreation\output\InVEST-recreation-log-2026-09-15–19_07_51.txt]

2026-09-15 19:07:52 natcap.invest.spec Level 100 Starting model with parameters:
Arguments for InVEST recreation 3.20.1:
aoi_path C:\InVEST\Meridien_recreation\dados\RJ_Municipio_UTM23S.shp
cell_size 1000
compute_regression False
end_year 2017
grid_aoi True
grid_type hexagon
n_workers -1
results_suffix test_15Set_1km_new
start_year 2017
workspace_dir C:\InVEST\Meridien_recreation\output

2026-09-15 19:07:53 natcap.invest.recreation.recmodel_client INFO PYRO:natcap.invest.recreation@34.56.65.180:54323

2026-09-15 19:07:53 natcap.invest.recreation.recmodel_client INFO gridding aoi

2026-09-15 19:07:56 natcap.invest.recreation.recmodel_client INFO Contacting server, please wait.

2026-09-15 19:07:56 natcap.invest.recreation.recmodel_client INFO flickr server supports year queries between 2005 and 2017

2026-09-15 19:07:56 natcap.invest.recreation.recmodel_client INFO AOI accepted. Fewer than 752847 flickr points found within AOI extent: [-43.78995827417918, -23.072561547689737, -43.155502138337305, -22.78104673692602]

2026-09-15 19:07:56 natcap.invest.recreation.recmodel_client INFO twitter server supports year queries between 2012 and 2022

2026-09-15 19:07:57 taskgraph.Task ERROR Something went wrong when adding task user-day-calculation (1), terminating taskgraph.
Traceback (most recent call last):
File “taskgraph\Task.py”, line 684, in add_task
File “taskgraph\Task.py”, line 1103, in _call
File “natcap\invest\recreation\recmodel_client.py”, line 745, in _retrieve_user_days
ValueError: The AOI extent is too large. The bounding box [-43.78995827417918, -23.072561547689737, -43.155502138337305, -22.78104673692602] contains up to 91158845 twitter points. Please reduce the extent of the AOI until it contains fewer than 40000000 points.

2026-09-15 19:07:57 natcap.invest.utils ERROR Exception while executing recreation
Traceback (most recent call last):
File “natcap\invest\utils.py”, line 169, in prepare_workspace
File “natcap\invest\spec.py”, line 2201, in execute
File “natcap\invest\recreation\recmodel_client.py”, line 563, in execute
File “taskgraph\Task.py”, line 684, in add_task
File “taskgraph\Task.py”, line 1103, in _call
File “natcap\invest\recreation\recmodel_client.py”, line 745, in _retrieve_user_days
ValueError: The AOI extent is too large. The bounding box [-43.78995827417918, -23.072561547689737, -43.155502138337305, -22.78104673692602] contains up to 91158845 twitter points. Please reduce the extent of the AOI until it contains fewer than 40000000 points.

2026-09-15 19:07:57 natcap.invest.utils INFO Elapsed time: 5.37s
2026-09-15 19:07:57 natcap.invest.utils INFO Execution finished; version: 3.20.1

2

Hi @mvale.eco,

Yes, unfortunately our server infrastructure is not really set up to handle very large jobs like this. It has more to do with the number of points in the area and the number of polygons in your AOI rather than the size of the AOI. A request like this might take 10s of hours (or more) to complete, and so we limit the size of queries in order to keep the server available to multiple users.

A plausible workaround would be for you to divide your AOI up into several smaller areas and run them each separately.

Also it is worth mentioning that the estimate of the query size that resulted in this message did not take into account that your query was limited to a single year (2017):

ValueError: The AOI extent is too large. The bounding box [-43.78995827417918, -23.072561547689737, -43.155502138337305, -22.78104673692602] contains up to 91158845 twitter points. Please reduce the extent of the AOI until it contains fewer than 40000000 points.

The data is indexed by location, not by time, so we don’t have a way to subset only the 2017 points before extracting all the points from all years in the location. Anyway, if your hope was to limit the years in order to get under the limit, that will not work and you might as well request as many years as you wish; it will not really impact the overall run time of the model.

3

Hi Dave,

Thank you very much for your quick reply! I wonder what area of interest would be smaller than a city… What area size would you recommend? My goal really was to generate the regressions, thus identify what influences visitation. I am afraid that if I chop the area into pieces, I won’t have the full picture regarding the covariates. Maybe what I can do is chop it into pieces to get the visitation data, then do the regression myself. Do you think that would make sense?

Do you have any reference that I can consult for recommendations on area size? Or should I focus on the number of records instead? For Twitter, there are 91.158.845 records; thus, assuming they are evenly distributed, dividing into three areas would return less than 4 million points, and that should be fine?
Thank you very much again for your help!

Mariana

4

You’re right, if you plan to do the regression then you probably want the entire area included in a single regression model. But as you suggest, you can do the regression yourself outside of invest after piecing the visitation data back together. In this approach you will have to process the predictor data on your own as well, since there’s not a way to run the model and skip the social media calculations.

To be honest, it is very common to want to do the regression modeling outside of invest because regression modeling is very much a “hands-on” process that should involve lots of data exploration and iterations. InVEST does not provide all that control.

Do you have any reference that I can consult for recommendations on area size? Or should I focus on the number of records instead? For Twitter, there are 91.158.845 records; thus, assuming they are evenly distributed, dividing into three areas would return less than 4 million points, and that should be fine?

Yes, it is the number of records that is the limiting factor, not the size of the area. The limit is 40 million points, so dividing your area into 3 or 4 pieces might be sufficient. The more pieces you have the faster each individual run will be. Based on your logfile, it looks like you chose to “grid the AOI” into cells of 1000 meters. So I would recommend starting from that “gridded AOI” (it should be in the output workspace of that failed run) and select 20% (or whatever portion you decide on) of the grid cells for each smaller AOI. Then when you do the subsequent model runs, be sure to change “Grid AOI” to False because you already have grid cells.

5

Got it!

Thank you so much, Dave.

Um abraço,

Mariana