[gdal-dev] Call for discussion on RFC76 OGR Python drivers

[Even Rouault]

Sean,

> About
> https://github.com/rouault/gdal/blob/pythondrivers/gdal/doc/source/tutorials
> /vector_python_driver.rst#driver-location, can you expand on the
> distribution/installation story for these plugins? Will there be any
> guidance about plugin dependencies? Will GDAL resolve and fetch them?
> Should they be vendored into the plugin?

I don't know what we could suggest. The RFC mentions " This RFC does not try 
to cover the management of Python dependencies. It is
up to the user to do the needed "pip install" or whatever Python package
management solution it uses."
GDAL will not do anything more than importing the module and running it, so 
the rules of the current environment will apply for any import directives in 
the .py file loaded by GDAL.
I can add that to the tutorial, or some better formulation that you may 
propose, if that helps ?

> 
> About
> https://github.com/rouault/gdal/blob/pythondrivers/gdal/doc/source/tutorials
> /vector_python_driver.rst#metadata-section, since the metadata are not
> likely to be used in the Python code, might they be defined at the top of
> the file in a commented line?  Cython directives are a good example:
> https://cython.readthedocs.io/en/latest/src/userguide/source_files_and_compi
> lation.html#globally .

Something like ?

# gdal: DRIVER_NAME = "BLA"

Why not

> 
> About the Driver interface, relying on drivers to register themselves as
> the handlers for filenames (with "identify") seems to me to open the door
> to conflicts and tricky bugs. Have you considered an XML (or whatever) file
> in the plugin directory as a registry?

I just replicate how a native driver works. The identify method can do 
whatever it wants to tell if a file is recognized by it or not (or if it 
cannot tell). It can look only at the extension, at the filename, at the 
content of the first bytes, or a combination of the above. This seems 
difficult to express in a non-programatic way. Although that's an idea I've 
had for a long time if we wanted to have less native drivers in the core lib 
and more .so that we would only load when they are needed. But that's out of 
scope for this work.

> 
> About the first bytes of the "file", what cases are you thinking of where a
> developer wouldn't be able to get them in the code they write? And how many
> bytes are we talking about?

This is just a matter of efficiency given the big number of drivers that GDAL 
has. If each driver had to open & close the file (particularly if they are on 
a network or some other slow /vsi) to be able to tell how if they recognize 
the file, that could be quite lengthy for the driver in the bottom of the 
list. So the GDALOpenInfo class opens the file and ingest the first 1024 
bytes. Some drivers might request more if that's not sufficient (but that API 
is not exposed to Python drivers). I'll had a note about 1024 being the 
minimum (but some drivers which might have run before might have increased it)

> 
> About the Layer interface, I feel like instead of offering two flavors: one
> based on GeoJSON and one based on the GDAL bindings, offer only one. Best
> practices will emerge faster, I think.

The one based on the GDAL bindings map on the capabilities of the GDAL data 
model, that have in addition to GeoJSON: style string, multiple geometry 
fields and geometry types not supported by GeoJSON. I thought that offering 
GeoJSON could make life simpler for some use cases. If I keep just one, then I 
should likely remove GeoJSON as it is less capable ?

> From what I see in the passthrough example, it looks like much of the
> "magic" of these plugins is going to be undone by requirements to prefix
> the connection strings with the name of the plugin driver. Is `ogrinfo
> PASSTHROUGH:myfile` any improvement over `python passthrough.py myfile`?

Ah, it is just an artificial example to demonstrate the full use of the API. 
The CityJSON one is more real world and doesn't require a connection string

Even

-- 
Spatialys - Geospatial professional services
http://www.spatialys.com