Joris Van den Bossche
Joris Van den Bossche
Indeed! Aside of that I am also aware of work ongoing in Sedona (Spark-based) to support GeoParquet: https://github.com/apache/incubator-sedona/pull/607
So when we are writing float columns that contain NaNs, we have two options: write those as NaN or as Null. Since the input data uses NaN, writing them as...
It would indeed be either all NaN or all Null, not a mix of them (which makes sense, because also pandas and numpy cannot represent a mix and so can't...
Sidenote: this also relates to potentially handling the experimental nullable dtypes of pandas more natively in pyogrio. For example the nullable integer data is represented with a data array +...
> Putting a CRS object on the GeoJSON like GDAL has done is no longer correct and reduces interoperability. Is this something that should also change on the fiona side...
Note that CRS84 or epsg:4326 are (for better or worse) in practice equivalent within geopandas, as we currently always store data as (x, y), regardless of the order prescribed by...
So just trying with a small reproducer, I see the same: ```python In [35]: df = geopandas.GeoDataFrame({'a': [0, 1], 'geometry': geopandas.points_from_xy([0, 1], [0, 1])}) In [36]: wkt = pyproj.CRS.from_authority("esri", 102005).to_wkt(pretty=True)...
One reason could be that OGC doesn't list ESRI is a valid value for `urn:ogc:def:crs` authority (https://www.ogc.org/ogcUrnPolicy, just a wild guess). Looking at the code, it might actually be that...
That means that `pyproj` is not installed correctly
I think a lot of this certainly makes sense. I personally currently don't have usecase of geospatial datasets that are larger than memory, but even for those in memory usecase,...