0

Is it possible to convert an ogr datasource into a geopandas GeoDataFrame without writing the datasource first as a physical file and reading it back? I am referring to something like

import ogr, geopandas

drv = ogr.GetDriverByName('MEMORY')
source = drv.CreateDataSource('test')
gdf = geopandas.GeoDataFrame(source)

The above throws an error:

Traceback (most recent call last): File "", line 1, in File "C:\ProgramData\Anaconda2\envs\wps_env36\lib\site-packages\geopandas\geodataframe.py", line 47, in init super(GeoDataFrame, self).init(*args, **kwargs) File "C:\ProgramData\Anaconda2\envs\wps_env36\lib\site-packages\pandas\core\frame.py", line 422, in init raise ValueError('DataFrame constructor not properly called!') ValueError: DataFrame constructor not properly called!

Which I get, no problem. However I find it hard to believe that you can't transfer data objects from ogr to geopandas and back without writing to physical files. What if you don't want to write a file because it is some part of an intermediate process you are trying to run?

Short of recreating the datasource feature by feature, geometry by geometry, field by field and, worst of all, transferring all the spatial reference data by writing custom wrapper functions, is there a way for ogr and geopandas to communicate?

  • 1) its not a layer, its a datasource. 2) trying source.Reference() throws error maximum recursion depth exceeded – user32882 Oct 12 '18 at 11:31
  • In reality the datasource is a result of the gdal_Polygonize routine. It contains polygons and attributes for each polygon feature. In the above example I simply create it without specifying a layer. It is a blank datasource, but thats just for demonstration purposes – user32882 Oct 12 '18 at 11:36
  • Please edit the question to provide details. It's not fair to those who would answer to need to mine the comments for necessary information. – Vince Oct 12 '18 at 12:49
  • What additional details would you like? I feel like it is a straightforward question.... – user32882 Oct 12 '18 at 12:59
  • 1
    The comments you have added should be merged into the question, then deleted. – Vince Oct 12 '18 at 13:04
2

The GDAL memory driver is written for GDAL and obviously exactly for improving the performance https://www.gdal.org/drv_memory.html as you wrote. The documentation seems to suggest that other processes can't open a memory datastore.

Memory This driver implements read and write access layers of features contained entirely in memory. This is primarily useful as a high performance, and highly malleable working data store. All update options, geometry types, and field types are supported.

There is no way to open an existing Memory datastore. It must be created with CreateDataSource() and populated and used from that handle. When the datastore is closed all contents are freed and destroyed.

GDAL memory rasters https://www.gdal.org/frmt_mem.html can be opened. The difference is probably that for memory raster it is possible to define the offset where the data begins in the memory:

It is possible to open an existing array in memory. To do so, construct a dataset name with the following format:

MEM:::option=value[,option=value...]

For example:

MEM:::DATAPOINTER=342343408,PIXELS=100,LINES=100,BANDS=3,DATATYPE=Byte, PIXELOFFSET=3,LINEOFFSET=300,BANDOFFSET=1

or

MEM:::DATAPOINTER=0x1467BEF0,PIXELS=100,LINES=100,BANDS=3,DATATYPE=Byte, PIXELOFFSET=3,LINEOFFSET=300,BANDOFFSET=1

DATAPOINTER: address of the first pixel of the first band. The address can be represented as a hexadecimal or decimal value. Hexadecimal values must be prefixed with '0x'. Some implementations (notably Windows) doesn't print hexadecimal pointer values with a leading '0x', so the prefix must be added. You can use CPLPrintPointer to create a string with format suitable for use as a DATAPOINTER.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.