Unable to add Observer or Target points LLOS or RLOS in Pro Add-In with elevation image service

[BobBooth]

I added the "Terrain" image service from "the living atlas", zoomed in close and tried to add LLOS target and observer points, got error message "Error Point does not fall within the input extent." Same thing happens with RLOS observer points (using Military Tools Add-in, Visibility tools). This error message is not helpful. Are image services supported? If not, disallow them as the Input surface in the Add-In. Is the coordinate system wrong (Web Mercator)? Let me know.

Data from:

Map coordinate system is WGS 1984 Web Mercator Auxiliary Sphere

ArcGIS Pro 1.4.1 Military Tools Add-In 03-01-2017_1228

[BobBooth]

Strangely, I am able to add points when I switch to the Ground Surface Elevation - 30m (from Portal), but the process is extremely laggy - I click and wait, and no points are added, no message given, then I click again, and a while later several points are added. The LLOS process even works on them.

[BobBooth]

Tried running one RLOS on the same elevation data - clicked to add one point in the same extent used above, accepted the Add-In defaults. ArcGIS Pro began processing... an hour later, it is still not finished. Pro using 38% of CPU and nearly 4GB of RAM.

[BobBooth]

Pro eventually crashed, when I was switching back to the Pro window. 25MB crash dump file resulted, FWIW.

[csmoore]

This is good holistic testing and there is a lot going on here so just trying to unpack (and make sure I have correct):

1. Surface Extent is not determined correctly when using the Living Atlas Terrain worldwide mosaic elevation service: http://www.arcgis.com/home/item.html?id=58a541efc59545e6b7137f961d7de883
2. Adding LLOS Observer/Target points (and the analysis) is slow when using NED30m elevation service from elevation.arcgis.com (https://elevation.arcgis.com/arcgis/services/NED30m/ImageServer)
3. Running RLOS on NED30m elevation service is incredibly slow and never finishes

And additional observations deriving from these:

4. It is not possible to cancel the slow LLOS and RLOS operations in Pro (have to kill Pro)
5. The addin does not warn you when you are about to do some potentially incredibly slow analysis (that might take minutes or even hours)

I'm not experienced at doing these kinds of analysis using remote services, is there is a realistic expectation to be able to run these kinds of analysis using these continent or worldwide (or even state-wide) remote services?

I would think the expected workflow is to define an Area of Interest & then extract the terrain from this area to create a local dataset for full analysis. If this is the expected/recommended usage then the solution might be to develop some strategies/warnings for documenting this expectation, and alerting the addin user to prevent this condition.

@mfunk @topowright @nfeuerstein @dfoll @kgonzago might also have a recommendation here - on using remote terrain services with the addin's local analysis tools.

[kgonzago]

Analysis should not be done on an AOI that large. @csmoore you brought up a good enhancement to the add-in: inform the user before executing analysis on a large AOI. User should cull the AOI to an appropriate size before execution. The add-in should not do that for them. The key now is to define what is an acceptable upper limit size for an AOI.

[BobBooth]

@kgonzago - True. Analysis should not be done on a huge AOI with image services >>but<< as far as the user is concerned, if they've input a point or three in the currently visible extent, especially for RLOS where the default is a relatively small radius around the input points, why is their analysis AOI any larger than the buffer area around those points? At maximum, their AOI should be the bounding box of the buffer zone around those points. We should be smarter about this. No need to pull down the whole extent. @csmoore - your workflow of "define an Area of Interest & then extract the terrain from this area to create a local dataset for full analysis" is what someone might currently need to do because of the clunky way we handle it now, but is it really the best way for the user to get their work done?

[mfunk]

Just catching up on this now. The original problem ""Error Point does not fall within the input extent" is almost always a mis-match between coordinate systems which is why the tools should always pick a spatial reference and project the "lightest" inputs to that spatial reference (in this case the observers/minimum bounding extent/buffer boundary).
As for AOI, how large is too large? A problem we've discussed a lot. Just keep in mind that this is a VISIBILITY analysis and is based on what you can SEE. Trying to do analysis across a continent is not well defined for this tool and not realistic based on sight. Next, make sure we are setting the environment up w.r.t. arcpy.env.mask, arcpy.env.cellSize, and arcpy.env.outputCoordinateSystem BEFORE we do much of the analysis. If we define the areas well and consider coordinate system we shouldn't have to clip the surfaces unless the surface SR is not suitable. Then, unsuitable surface spatial references (geographic and non-equidistant projections) might force us to clip, but again try to do this in_memory for small resolution areas, in %scratchGDB% for large areas, and tell the user its going to take time. We tried to do this in the RLOS gp tool, but its still not perfect because of the number of types of rasters (dataset, layer, mosaic, image service), and coordinate system issues (everything goes to local Az Ed based on observers), and need for tighter control (earth curvature, viz control modifiers, etc.). Too much at once and somehow I'm feeling it's not helping a whole lot.

[BobBooth]

@mfunk - re "Just keep in mind that this is a VISIBILITY analysis and is based on what you can SEE. Trying to do analysis across a continent is not well defined for this tool and not realistic based on sight." - absolutely. But if I'm zoomed to a mountainous area (say 1:10,00 scale) and I've added points to to use for my analysis, I've implicitly defined an AOI - there is no reason to be pulling down the whole continent.

[BobBooth]

So, at 1:11,000 scale, on my monitor, this area is only ~2,700m across. Pro can load all the cells to display them, reasonably quickly. If I zoom to the raster resolution: then the area is 35 km across. Big, but not terribly big. Again, all of the pixels loaded reasonably fast. They're all "there" aleady... If I add a point at this zoom level (where one pixel on my monitor is equal to one pixel in the raster, if Pro is telling me the truth) and use the default inputs for a RLOS (1000m), why should the area examined for visibility be any larger than a square 2,000 m on a side. Since these pixels are 30m square, that AOI is only 66 x 66 pixels.

[csmoore]

I added a temporary workaround to this problem in #193 until we can fully resolve.

The problem that occurs in Pro (not ArcMap) is that when a new point is added, it is checked against the extent of the surface and this call to ImageServiceLayer.QueryExtent() is taking several minutes to return - during which Pro is unresponsive.

To fully fix we should:

1. submit a bug against Pro SDK ImageServiceLayer.QueryExtent() taking several minutes to return with some image services (ex. the one above: http://www.arcgis.com/home/item.html?id=58a541efc59545e6b7137f961d7de883)
2. get guidance on an alternate method for getting the extent of ImageServiceLayer (like Pro is able to do on properties page, screenshot below)

[NatalieCampos]

This issue has been resolved with the fix for the image service warning. Closing issue.