feat: geopandas extension; explore method

[knaaptime]

supercedes #728

[kylebarron]

I think it's probably worth having this in a lonboard.geopandas module. It can stay self contained and then we can document it could change in a backwards incompatible way across versions

A couple questions on the mechanics of how this works:

• Judging from the pandas docs, as soon as pd.api.extensions.register_dataframe_accessor is called in global scope, the accessor is available, right? So with the current layout, once a user calls import lonboard.geopandas, the GeoDataFrame.lb accessor is already available?
• Should we have some API for the user to register/unregister the accessor?
• @martinfleis any preference on the namespacing? .lb? .lon?
• Is there any way to support user-facing type hints here? I'm pretty sure the answer is usually no for these kind of extension mechanisms, but it would be nice if users could get some IDE help

[martinfleis]

So with the current layout, once a user calls import lonboard.geopandas, the GeoDataFrame.lb accessor is already available?

yes

Should we have some API for the user to register/unregister the accessor?

I don't think so.

any preference on the namespacing? .lb? .lon?

no strong feelings, lon may conflict more with the real column name.

Is there any way to support user-facing type hints here?

No clue.

[kylebarron]

any preference on the namespacing? .lb? .lon?

no strong feelings, lon may conflict more with the real column name.

Good point. Let's use lb.

[knaaptime]

for some reason the precommit hook removes the import lonboard.geopandas line from the example notebook

[kylebarron]

I think you can put # noqa: F401 at the end of the import line