Select to view content in your preferred language

What's Up with SpatialDataFrame Documentation?

07-19-2017 12:45 PM
MVP Esteemed Contributor

Am I missing something or is the SpatialDataFrame documentation quite incomplete?  According to the documentation, there are < 20 properties and methods for SpatialDataFrame class, but when I instantiate a SpatialDataFrame there are >250 properties and methods.  I understand a SpatialDataFrame might inherit properties and methods from other classes, but 230 without any documentation?

There are numerous issues I see with SpatialDataFrames, but the one I know will cause problems right away is multiple "shape" properties.  When importing a feature class into a SpatialDataFrame, a property named "SHAPE" is created that returns a GeoSeries.  Additionally, there is a "shape" property that comes from a pandas DataFrame that returns the dimensionality of the DataFrame.  Having "SHAPE" and "shape" properties on the same object will inevitably cause confusion and coding mistakes.

There are some neat/nice features added with 1.2, but I really think the product has gotten way ahead of the documentation. 

0 Kudos
5 Replies
MVP Emeritus

Joshua... is numpy supported directly without having to go through the Panda's fluff?

It will be of no interest to me if it isn't since Panda's is too slow for many tasks that I need

0 Kudos
MVP Esteemed Contributor

Not exactly sure, will have to take a deeper dive and get back with you.  As I mentioned, the gap between the documentation and API itself is making this a figure-it-out-as-I-go kind of learning.

0 Kudos
MVP Emeritus

answered my own question sadly....

Help on class SpatialDataFrame in module arcgis.features._data.geodataset.geodataframe:

class SpatialDataFrame(arcgis.features._data.geodataset.base.BaseSpatialPandas, pandas.core.frame.DataFrame)
 |  A Spatial Dataframe is an object to manipulate, manage and translate
 |  data into new forms of information for users.
 |  Required Parameters:
 |    None
 |  Optional:
 |    :param data: panda's dataframe containing attribute information

..... etc etc etc‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

There is some hope

df = arcgis.SpatialDataFrame.from_featureclass(fc1)
   OBJECTID_1  OBJECTID  DrainID   Shape_Leng   EASlope Test  \
0           1         5    10059  2445.372364  6.508173    E   
1           2         6    10061  1904.024600  9.468992    F   

0  {'hasZ': True, 'paths': [[[74653.39319999982, ...  
1  {'hasZ': True, 'paths': [[[75298.39319999982, ...  

a_df = arcgis.SpatialDataFrame.to_records(df)
rec.array([ (0, 1, 5, 10059, 2445.37236354, 6.50817328097, 'E', {"hasZ": true, "paths": [[[74653.39319999982, -3464650.4749999996, 334.29649999999674, null], [74654.63260000013, -3464651.7144, 334.39949999999953, null], [74657.13260000013, -‍‍‍‍‍‍‍‍‍‍‍‍‍
Esri Regular Contributor


the inheritance from the base object (Panda's Dataframe), imports all the functions.  I felt that those functions do not need to be documented since we did not write them, and they can be found on the panda's dataframe.

Dan basically posted where you can get class specific help.


With the SHAPE and shape issue you are seeing, is actually a function of the panda's dataframe itself.  It allows for '.' (dot) notation for field names.  

MVP Esteemed Contributor

Andrew, thanks for the reply.  I guess I am not used to subclassing packages/classes that have hundreds of properties/methods, so I wasn't expecting to see all of them.  It is a bit different with GeoPandas since it is "geo-enabled" pandas.

Regarding "SHAPE" and "shape", I understand why there are two fields (the pandas automatic field mapping), but I know it will cause confusion in my organization with people working with the API, at least at first, and I suspect that will be the case for others as well.  Seeing there is already a SpatialDataFrame.geometry property that gets the geometry series, maybe the geometry column doesn't have to be made available using its name, i.e., ".SHAPE" wouldn't exist since .geometry does.

0 Kudos