Does spatialpandas read shapefiles or do I need to convert from geopandas?

[andhuang-CLGX]

as title says

[jbednar]

Spatialpandas objects have a from_shapely classmethod (see e.g. https://github.com/holoviz/spatialpandas/blob/master/spatialpandas/geometry/ring.py), which looks like it would work if you use Shapely to read it.

[brl0]

@andhuang-CLGX, I would definitely suggest reading shapefiles with geopandas and then converting that to a spatialpandas dataframe.

[avriiil]

@brl0 - could you say something about why this is the recommended approach? Are there plans to add an equivalent of geopandas.read_file('file.shp')?

[jorisvandenbossche]

I think this is the recommended approach, because this is the easiest way to get data from a shapefile into spatialpandas. A shapefile is a custom format for which you need a (nontrivial) reader, and that isn't included in spatialpandas. One way is thus to use geopandas (actually fiona or pyogrio, wrapping GDAL). Another way could be to use pyshp if you want to avoid a GDAL dependency, but then you will still have to do the conversion from the pyshp output to what spatialpandas needs yourself.

[jbednar]

We definitely do not want to try to make SpatialPandas compete with GeoPandas for what GeoPandas already does!

[brl0]

@rrpelgrim,

I think issue #1 is a great reference from the original author of the package on the topic. Specifically:

Non-goals

spatialpandas will be focused on geometry only, not geography. As such:

• No built-in support for loading data from geography-specific file formats
• No dependency on GDAL/fiona
• No coordinate reference frame logic

I do wonder if some projects like pyshp, which was previously mentioned, would benefit from offering spatialpandas as an output option.

I think spatialpandas is great for us, particularly for distributed workloads, but considering some of the great work they have been doing on dask-geopandas, so I'm not sure how much additional value it offers the ecosystem to add many more features here. That said, I think if other lightweight geospatial packages were interoperable with it, it could be very beneficial for users looking to avoid the heavier and occasionally fragile stack of dependencies geopandas is built on top of. But it is hard to imagine ever approaching feature parity, considering the amazing depth of functionality that stack provides.

It should also be noted, that ultimately this project is under the holoviz team organization, who potentially, and justifiably, may be somewhat sensitive to adding features that would become future maintainability challenges.

[jbednar]

We at HoloViz would never complain about other packages like pyshp generating spatialpandas compatible output. 🙂

The original author of issue 1 has moved on from our group, so it's up to me now, I guess. BTW, we will soon be looking at whether Awkward arrays could work as a basis for spatialpandas, and if so the task would then be to connect pyshp with Awkward. Can't really look at that until June, though!

[brl0]

@jbednar, Your timing in mentioning Awkward is well timed, I literally just clicked to this notification coming from dask-awkward. It is exciting to see you guys moving that forward. :)

Coincidences aside, I really appreciate the efforts, both voluntary and involuntary, you and your team put in to supporting the community, and the same goes for @jorisvandenbossche and the geopandas team. It's amazing how much work and effort goes into building up this ecosystem.