Optimized Hotspot Analysis tool failing when Cell Size is set

484
2
Jump to solution
05-08-2019 05:39 AM
Highlighted
New Contributor

I just updated to ArcGIS Pro 2.3.2.  The Optimized Hotspot Analysis tool is giving me the following error.  I've been running the same parameters for a few months now and this is the first time I've had this issue, and only after upgrading.  Is there a way to fix this?


Parameters
Input Features PresentGMI2019
Output Features C:\Users............
Analysis Field
Incident Data Aggregation Method COUNT_INCIDENTS_WITHIN_HEXAGON_POLYGONS
Bounding Polygons Defining Where Incidents Are Possible Precincts
Polygons For Aggregating Incidents Into Counts
Density Surface
Cell Size 1320 Feet
Distance Band

Messages
Start Time: Wednesday, May 8, 2019 8:26:06 AM
Running script OptimizedHotSpotAnalysis...
WARNING 001605: Distances for Geographic Coordinates (degrees, minutes, seconds) are analyzed using Chordal Distances in meters.
ERROR 110250: All grid cells must fall within the projection domain.
Failed to execute (OptimizedHotSpotAnalysis).
Failed at Wednesday, May 8, 2019 8:26:09 AM (Elapsed Time: 2.54 seconds)

Reply
0 Kudos
1 Solution

Accepted Solutions
Highlighted
Esri Contributor

Hi Daniel,

Just looking at the error, I would say it might be a good idea to check if your data is a) in a geographic coordinate system and b) has an extent more than 30 degrees, if so.

https://pro.arcgis.com/en/pro-app/tool-reference/spatial-statistics/optimized-hot-spot-analysis.htm

According to the documentation:

When the Input Feature Class is not projected (that is, when coordinates are given in degrees, minutes, and seconds) or when the output coordinate system is set to a Geographic Coordinate System, distances are computed using chordal measurements. Chordal distance measurements are used because they can be computed quickly and provide very good estimates of true geodesic distances, at least for points within about thirty degrees of each other. Chordal distances are based on an oblate spheroid. Given any two points on the earth's surface, the chordal distance between them is the length of a line, passing through the three-dimensional earth, to connect those two points. Chordal distances are reported in meters.

Caution:

Be sure to project your data if your study area extends beyond 30 degrees. Chordal distances are not a good estimate of geodesic distances beyond 30 degrees.

If your data are in a geographic coordinate system, maybe try projecting your data and trying again. Does that resolve the error?

I hope so!

-Lauren

View solution in original post

Reply
0 Kudos
2 Replies
Highlighted
Esri Contributor

Hi Daniel,

Just looking at the error, I would say it might be a good idea to check if your data is a) in a geographic coordinate system and b) has an extent more than 30 degrees, if so.

https://pro.arcgis.com/en/pro-app/tool-reference/spatial-statistics/optimized-hot-spot-analysis.htm

According to the documentation:

When the Input Feature Class is not projected (that is, when coordinates are given in degrees, minutes, and seconds) or when the output coordinate system is set to a Geographic Coordinate System, distances are computed using chordal measurements. Chordal distance measurements are used because they can be computed quickly and provide very good estimates of true geodesic distances, at least for points within about thirty degrees of each other. Chordal distances are based on an oblate spheroid. Given any two points on the earth's surface, the chordal distance between them is the length of a line, passing through the three-dimensional earth, to connect those two points. Chordal distances are reported in meters.

Caution:

Be sure to project your data if your study area extends beyond 30 degrees. Chordal distances are not a good estimate of geodesic distances beyond 30 degrees.

If your data are in a geographic coordinate system, maybe try projecting your data and trying again. Does that resolve the error?

I hope so!

-Lauren

View solution in original post

Reply
0 Kudos
Highlighted
New Contributor

Projecting the data has fixed the issue, though I'm still not sure why. 

I'm only running the tool on a single city with the city boarder bounded, roughly 20x25 square miles, and the tool ran successfully when the cell size was not set.  Which probably would have been fine, except for there being no cell size consistency between several maps I make on a weekly basis.  I never had issue before I updated the program.  

Reply
0 Kudos