Joris Van den Bossche

If you look at eg https://gdal.org/drivers/vector/gpkg.html or https://gdal.org/drivers/vector/shapefile.html, I think in general the most relevant options are "layer creation options". So personally I would keep the convenience of automatically passing...

It seems that Fiona passes the `kwargs` to both the dataset and layer creation. And I suppose that GDAL will then ignore the ones that are not relevant?

Although we use `BytesCollection` in the geopandas `read_file` implementation, fiona actually also has a `MemoryFile`, which seems a more advanced implementation of this. Without further looking, I don't directly know...

Indeed, for _reading_ it's also my conclusion that the simpler version (similar to the BytesCollection in fiona, as referenced in the top post) should be sufficient for our use case....

One possible alternative I have been mentioning in earlier discussions (eg https://github.com/geopandas/geopandas/pull/1191), is a "nested list" array (variable size `ListArray` in Apache Arrow), which essentially stores a flat array of...

> I understand that existing GEOS, GeoPandas memory models, etc are different, and we can't satisfy all existing needs with a single in-memory format. To be clear: GeoPandas main memory...

Indeed, with `pygeos` we are still storing GEOS objects in numpy arrays (just a bit different / more efficiently as with current Shapely).

When it comes to different memory layouts / binary encodings, it probably makes sense to look at some prior art. One recent effort is **flatgeobuf** (https://github.com/bjornharrtell/flatgeobuf/: *"A performant binary encoding...

@dcooley you show here an array with linestrings with mixed dimensions (one with x,y, and the other with x,y,z). Do you think that is important to support within a single...

@thomcom thanks a lot for chiming in! (and sorry for the late reply, was offline for some time ;-)) > What I'm working on is an Arrow format for cuSpatial's...