#QNAN problem with a polygon geometry when using argisscripting module... why??

Discussion created by peterlen on May 5, 2014
Latest reply on May 5, 2014 by peterlen
We are using Python v2.6 with ArcGIS 10.  I am trying to debug an issue with an application we inherited and ran across an odd issue.  There is a process that takes KML files and ingests the polygon objects into an geodatabase.  Each KML contains only polygon objects and each polygon contains 5 coordinates (the 5th to close the polygon).  For the vast majority of KML items, there is no problem but we have recently run into a #QNAN (Quiet Not A Number) error on some of them.  In debugging the code, the error is caused when the string value #QNAN is used in a float() operation.  we found that the #QNAN value was being produced from the process in creating a polygon geometry object using the arcgisscripting module.  More specifically, the polygon object's extent contains #QNAN rather than coordinates.    I loaded the KML polygon placemark definition in Google Earth and all seems fine.  The polygon looked to be a sliver that was roughly 76,000 sq meters.  I fiddled with the latitude coordinates a bit to make the polygon slightly larger and found that it would NOT fail when the polygon was little bigger (ie more area).  This made me think that the arcgisscripting module could not generate a valid polygon object if the polygon's bounding coordinates were below some threshhold.   This seemed a little odd though for a polygon that was 76,000 sq meters, which while not large, is not small.  Below is the info concerning the coordinates and arcgsiscripting code:

coords =

gp = arcgisscripting.create()
gp.Overwriteoutput = 1
gp.OutputCoordinateSystem = "Coordinate Systems/Geographic Coodinate Systems/World/WGS 1984.prj"
.........   # Add points to an array
poly = gp.createObject("geometry", "polygon", array)

poly.extent would then = 1.#QNAN 1.#QNAN 1.#QNAN 1.#QNAN

In fiddling with the latitude, for eaxmple, I would change 56.27583333299998 to 56.279 and it would work.  There was some threshold to get it to work.  Using 56.276 and 56.277 would not work as well.  Again, this problem occurs for only a small number of the KML polygon placemarks.  I don't know exactly how many, however, because when one of these particular polygons is encountered during the ingest, the rest of the KML is not processed.

I ran tests using arcpy instead of arcgisscripting and found that the problem did not exist.  At first the results were showing that even the arcpy version was failing because it was giving 1.#QNAN as well, until I realized that I had not added the coordinate system.  Then it worked fine.

So......  my conclusion is that the arcgisscripting module has some limitation on creating polygon objects that are smaller than some threshhold, but what gets me is that a polygon rectangle of roughly 76,000 sq meters does not seem small.  Maybe it isn't so much the area but how narrow the latitude or longitude bands are.

Does anyone have any thoughts on whether this is in fact an arcgisscripting limitation??  My hope is that it can still work properly with aercgisscripting if X or Y is changed because moving to arcpy may be out of the question.

Thanks for any thoughts - Peter