Not sure if that's the intended direction of this discussion, but Categorical can now be inserted into a dataframe (and is used as a backend) like a numpy ndarray, so I think it is possible to convert GeoSeries into a GeoArray (and probably also add a GeoIndex) and use pd.DataFrame directly (which probably needs a merge, as this would need some changes on the pandas side -> see the Categorical works in https://github.com/pydata/pandas/pulls?q=is%3Apr+label%3ACategorical+is%3Aclosed).

This is something I'm really starting to support... especially after dealing with all the typing issues that seem to keep popping up and feel unavoidable.

We actually discussed and made a basic implementation of this back in #69, but ultimately decided against it. I think now that .cat and .dt are there, a .geo is only natural.

The only immediate questions that come to mind are how to store the extra information that needs to travel along with GeoSeries or a would-be GeoArray... particularly, the crs and rtree. Maybe this mechanism already exists, but not sure now... I'll have to take a deeper look at how Categorical and dt are implemented. The crs could be solved with something like Shapely #132, but not sure how to move the rtree around appropriately...

Hoping to hear from the other GeoPandans about this too.

Look at Categorical: If you want to stuff some object into a pandas.DataFrame, it needs to support the methods, which the blockmanager calls on this object (see pandas/core/categorical.py) and a Spoecial Blocl (see pandas/core/common.py). And some special casing in the rest of pandas, which you get from using it :-) Have a look at pandas-dev/pandas#7217, which implemented most of it (there are two more fixup, which found places where pandas didn't handle categorical data)

s.dt is "only" an accessor for a DateTimeIndex(self) and s.cat is similar, the "categoricals as a block" is in the above PR...

@JanSchulz This was indeed my intended direction for this discussion. Categorical is a very nice precedent, though I'm not sure if pandas is ready to support the necessary public API.

@jwass Yes, I think the right approach would be to store the crs and rtree as GeoArray attributes. This would be sort of similar to how pandas handles datetime arrays, which have an associated timezone.

One other thing -- when/if this does happen, it would be great if it can work for ndarrays, not just 1d arrays (like categorical currently). I can imagine multi-dimensional geoarrays working great for raster data... perhaps even some sort of mash up with xray (my project for multi-dimensional pandas-like data structures).

@shoyer In Categorical, the public API is contained to the accessor (any Categorical itself). I think the more problematic change is that the rest of the codebase assumes in a few places that it gets a numpy array and this would need special casing (like with Categorical).

I'm coming around on the geo accessor, especially seeing how it can be consistent with other pandas usage. I'm less sure about the other attributes, we'll have to think on that a bit.

What I'd like to do as a next step is get a stable 0.2 release with spatial indexing and spatial joins, then we can look at doing some design for the next version.

@JanSchulz The real problem, of course, is that there is no standard way to write numpy ndarray-like objects that cannot or should not be actual ndarrays (e.g., because it's overkill to write C). Something like an abstract base class for ndarray like objects. I feel that this something more fundamental than pandas, but I don't even know where it belongs (numpy? blaze?).

Categorical is a subclass ofPandasObject, but that is not a subclass np.ndarray, so no C or Cython. There was some talk about implementing Categorical as a np.dtype.

@JanSchulz Yep. I guess what I'm saying is, I wish it was easier to write custom dtypes, such as categorical and geo data without the C.

The discussion about dtypes seems to be getting a little off-topic here, so I posted to the numpy mailing list: http://mail.scipy.org/pipermail/numpy-discussion/2014-September/071231.html

Looks like a duplicate of #680 (comment) (which has a more in-depth discussion)