Feature/249 support geoparquet #254
Conversation
|
The pipeline failed but it seems just to be an intermittent networking issue, from the raw logs
|
| @@ -206,10 +234,20 @@ def default_title(obj, name): | |||
| import pandas as pd | |||
|
|
|||
| if isinstance(obj, pd.DataFrame): | |||
| try: | |||
There was a problem hiding this comment.
this might play really nicely with the changes you've made in #263 👀 What if we merge that PR first and then refactor geopandas dataframes to be part of _get_df_family?
There was a problem hiding this comment.
Totally agree.
| # TODO(compat): title says CSV rather than data.frame | ||
| # see https://github.com/machow/pins-python/issues/5 | ||
| shape_str = " x ".join(map(str, obj.shape)) | ||
| return f"{name}: a pinned {shape_str} DataFrame" | ||
| return f"{name}: a pinned {shape_str} {obj_name}" |
There was a problem hiding this comment.
also, as someone who is not a geopandas frequent flyer-- is it important to you to denote that it is a geopandas dataframe, rather than just "DataFrame"? I partially ask since we won't specify between pandas/polars (although I do realize that is mostly due to the fact polars dataframes do not round-trip)
There was a problem hiding this comment.
Good point - I think GeoDataFrame would be more informative in this case.
There was a problem hiding this comment.
GeoDataFrames contain extra metadata such as a coordinate system, an assigned geometry column, and in general "feel" quite different to a standard DataFrame. The naming convention reflects this: using _gdf in variable names instead of _df.
nathanjmcdougall
force-pushed
the
feature/249-support-geoparquet
branch
from
701248d to
da71966
Compare
To resolve #249.
I am developing on Windows so adding a dependency and updating the requirements file is a little cumbersome.
The way I approached this is to use
uvwithuv pip compile setup.cfg --extra=doc --extra=test --python-platform=linux --output-file=requirements/dev.txt --unsafe-package=pip --unsafe-package=setuptoolsAnd then I did some massaging of the diff to remove some unnecessary stylistic changes introduced by uv.
Also pip-compile ignores platform specifiers, so
uvdidn't includeappnope==0.1.4(it is a Darwin-only dependency ofipykernel), but I manually added it back to minimize the diff.This might be an argument in favour of switching to
uv pip compileoverpip-compilebut it also might be an argument in favour of me developing on Linux 👀