Land Analysis for Arizona HUCs Not Working on Staging

[rajadain]

Cave Creek HUC-10 results in an error on staging:

But success on production:

This is only seen for the Land Analysis

View details in Rollbar: https://rollbar.com/WikiWatershed/ModelMyWatershed/items/78/

Traceback (most recent call last):
  File "/usr/local/lib/python2.7/dist-packages/celery/app/trace.py", line 374, in trace_task
    R = retval = fun(*args, **kwargs)
  File "/usr/local/lib/python2.7/dist-packages/celery/app/trace.py", line 629, in __protected_call__
    return self.run(*args, **kwargs)
  File "apps/geoprocessing_api/tasks.py", line 115, in analyze_nlcd
    raise Exception('[analyze_nlcd] {}'.format(result['error']))
Exception: [analyze_nlcd] Geoprocessing Error.
Details: java.util.NoSuchElementException: key not found: SpatialKey(64,130)

[rajadain]

This is possibly because NLCD analysis results on staging are tied to ARA data as of #3200, which may not have data throughout the Continental United States. Handling cases when that has NODATA should fix this.

[rajadain]

The error is coming from the geoprocessing service. One option may be to update the geoprocessing service to return null instead of erroring out. The concerns with that approach are:

• Returning an error may be the more "correct" thing to do, as a null may imply that the extent does cover it, but there is no data in that area
• Updating the geoprocessing service requires its own deployment steps, although no special steps need to be taken during MMW's deployment, which would include the new service automatically
• Still, touching an otherwise correctly part of the system introduces possibilities of errors

Another approach is to re-ingest the raster so that it has null values for the rest of the country. The concerns with this approach are:

• Ingests are time-consuming processes
• We have other datasets that are also limited in extent (Shippensburg Land Predictions, possibly more). Do we apply this only to the ARA raster, and be inconsistent? Or do we apply this to all the rasters to be consistent, and embark a potentially expensive and error prone process.

Another approach is to change the Celery workflow in Python to query for Land and ARA results separately. That way, if one errors out, the other can still complete. If returned correctly, the value can be included in the final result. The concern with this method is:

• Firing off a request not knowing if it will succeed or fail introduces "expected" errors in the workflow, which is not great design. We should use exceptions as exceptions, not as if clauses
• Having multiple geoprocessing calls introduces risk of celery_unlock floods in the workers

Whether a request will pass or fail is testable given information at design time and run time, namely the area of interest and the extent of the ARA raster. We can generate a perimeter of the ARA raster (a-la DRB or NHD or PA that already exist) and test the area of interest against it, querying for it only when it is available. Otherwise, the back-end can send an "out of extent" signal which can be used by the front-end to hide that line of information, when it is introduced in #3202.