In-Memory datasets and Shape_Area field

6195
12
12-15-2010 12:12 PM
KenBuja
MVP Esteemed Contributor
When creating an in-memory feature layers from the Dissolve tool, the resulting feature layer contains the fields Shape_Length and Shape_Area. However, the attributes in both these fields are null. However, if the Dissolve tool's output is a scratch geodatabase, these two fields are populated correctly. Why aren't these field populated for in-memory feature layer?
0 Kudos
12 Replies
ChrisSnyder
Regular Contributor III
Not sure as to the techincal reasonm why, but they aren't persisted in the in_memory workspace.

In v93 at least, if you copy an on-disk FGDB format feature class to the in_memory workspace (using  CopyFeatures), you will note the ABSENCE of the Shape_Area and/or Shape_Length fields. Maybe ESRI thought them a waste of space to store in RAM since you can easily recover them using the !SHAPE.area! and/or !SHAPE.length! properties?

Are you specifying the Shape_Area and Shape_Length fields as dissolve items? Not sure why they would be persisting the in_memory output...
0 Kudos
KenBuja
MVP Esteemed Contributor
I'm running a Dissolve (in ArcGIS 10) on a shapefile that doesn't contain the Shape_Area field and am selecting a text field for the dissolve item. It adds Shape_Length and Shape_Area fields to the resultant feature layer and I cannot do anything with those two fields (Delete, run the Field Calculator, or Calculate Geometry). When I export the in-memory feature layer to a shape files, both field are retained as Long fields with a value of 0.
0 Kudos
ChrisSnyder
Regular Contributor III
Ken,

I reproduced this behavior in v10 (doesn't happen in v9.3 BTW). Seems like a bug to me... In v9.3, this did not happen (bogus Shape_Area and Shape_Length fields being created and persisted for in_memory featureclasses when the input is a shapefile with no Shape_Area or Shape_Length fields).

This would be funny if it's true, but I actually might be partially to blame here since I submitted a bug to ESRI a long time ago (http://resources.arcgis.com/content/nimbus-bug?bugID=TklNMDA2ODA5) complaining how the Shape_Area and Shape_Length fields were dropped (in v93) when a feature class was stored in_memory. This could very well be the bug "fix" - which of course is all fdup when using a shapefile as input. Funny what happens when you have non-GIS people programming GIS software...
0 Kudos
KenBuja
MVP Esteemed Contributor
ESRI has issued Bug NIM063795 about this behavior. It occurs when the background processing is enabled.
0 Kudos
GraemeBrowning
Occasional Contributor III
I encountered the same issue (discussed above) today and so developed the Python test script below to demonstrate it.

If you run it the expected result is to see the shape area figure printed 3 times but you only see it twice accompanied by the Python error below the code.

The error is seen at ArcGIS 10.0 SP4 so I am hoping might be addressed by 10.1. Could someone with 10.1 Pre-release already installed perhaps run the test and see if the problem persists.

If in_memory workspaces work like this by design rather than oversight perhaps that can be documented in the 10.1 Online Help (that is now accessible via resources.esri.com).

In my application I will be able to workaround it by using CopyFeatures_management to get the feature class back on disk before trying to access its Shape_Area but I'm iterating through 100+ feature classes so would have preferred not to lose that copying time. The in_memory is otherwise working very well to perform 100+ iterations of Intersect between the CopyFeatures to and now as a workaround from in_memory.

import arcpy

if arcpy.Exists("C:/Temp/Test.gdb"):
    arcpy.Delete_management("C:/Temp/Test.gdb")

if arcpy.Exists("in_memory"):
    arcpy.Delete_management("in_memory")

arcpy.CreateFileGDB_management("C:/Temp","test","CURRENT")

arcpy.CreateFishnet_management("C:/Temp/test.gdb/fishnetPolys","0 0","0 1","1","1","1","1","#","NO_LABELS","#","POLYGON")

fcs = arcpy.SearchCursor("C:/Temp/test.gdb/fishnetPolys")
for fc in fcs:
    print fc.Shape_Area
    print "Above came from Shape_Area field of polygon on disk"
del fc,fcs

arcpy.CopyFeatures_management("C:/Temp/test.gdb/fishnetPolys","in_memory/fishnetPolysInMemory")

arcpy.CopyFeatures_management("in_memory/fishnetPolysInMemory","C:/Temp/test.gdb/fishnetPolysBackOnDisk")

fcs = arcpy.SearchCursor("C:/Temp/test.gdb/fishnetPolysBackOnDisk")
for fc in fcs:
    print fc.Shape_Area  
    print "Above came from Shape_Area field of polygon copied from disk to in_memory and back to disk"
del fc,fcs

fcs = arcpy.SearchCursor("in_memory/fishnetPolysInMemory")
for fc in fcs:
    print fc.Shape_Area
    print "Above came from Shape_Area field of polygon copied from disk to in_memory - but you should see error trying to access it"
del fc,fcs


>>> ================================ RESTART ================================
>>>
1.00024415553
Above came from Shape_Area field of polygon on disk
1.00024415553
Above came from Shape_Area field of polygon copied from disk to in_memory and back to disk

Traceback (most recent call last):
File "C:/Organisations/Qld DERM/SHAPE_Area_bug.py", line 31, in <module>
print fc.Shape_Area
File "C:\Program Files\ArcGIS\Desktop10.0\arcpy\arcpy\arcobjects\_base.py", line 25, in __getattr__
x = getattr(self._arc_object, attr)
RuntimeError: Row: Field Shape_Area does not exist
>>>


Note: Background processing is not involved when I see this.
0 Kudos
GusMartinka
Occasional Contributor
I am seeing this problem in 10.1 too. Background processing appears to have no effect. 

You can take a feature class stored on disk, list its field to see "shape_length" then copy that feature class to in memory storage and list the fields again to find that "shape_length" is no longer there.

To work around the problem I added my own shape_length field to the in memory feature class and calculated it.
0 Kudos
AbhijitRaikhelkar1
New Contributor

Looks like this issue is not resolved for 10.5.1 too. I had to do the similar thing of creating new field and calculating lengths. But its simpler to just get the attribute as is. I think ESRI has to look into fixing this, especially when in-memory is used for faster processing.

0 Kudos
GraemeBrowning
Occasional Contributor III
ESRI has issued Bug NIM063795 about this behavior. It occurs when the background processing is enabled.


Thanks Ken

However, for me it is not restricted to background geoprocessing.

- Graeme
0 Kudos
KenBuja
MVP Esteemed Contributor
Thanks Ken

However, for me it is not restricted to background geoprocessing.

- Graeme


You should contact Esri support to add this information to the bug.
0 Kudos