What's Up with SpatialDataFrame Documentation?

[JoshuaBixby]

Am I missing something or is theSpatialDataFrame documentationquite 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.

[DanPatterson_Retired]

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

[JoshuaBixby]

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.

[DanPatterson_Retired]

answered my own question sadly....

help(arcgis.SpatialDataFrame)Help onclassSpatialDataFrameinmodule arcgis.features._data.geodataset.geodataframe:classSpatialDataFrame(arcgis.features._data.geodataset.base.BaseSpatialPandas,pandas.core.frame.DataFrame)|A Spatial Dataframeisan object to manipulate,manageandtranslate|data into new forms of informationforusers.||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)df OBJECTID_1 OBJECTID DrainID Shape_Leng EASlope Test \015100592445.3723646.508173E126100611904.0246009.468992F SHAPE0{'hasZ':True,'paths':[[[74653.39319999982,...1{'hasZ':True,'paths':[[[75298.39319999982,...a_df=arcgis.SpatialDataFrame.to_records(df)a_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,-

[AndrewChapkowski]

Joshua,

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.

help(arcgis.SpatialDataFrame)

你看到的形状和形状问题,actually a function of the panda's dataframe itself. It allows for '.' (dot) notation for field names.

[JoshuaBixby]

安德鲁,谢谢e 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 aSpatialDataFrame.geometryproperty 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.