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

[Sean Gillies]

Hi Even,

On Mon, Nov 11, 2019 at 7:21 AM Even Rouault <even.rouault at spatialys.com>
wrote:

> On mercredi 6 novembre 2019 00:02:52 CET Mateusz Loskot wrote:
> > On Tue, 5 Nov 2019 at 12:06, Even Rouault <even.rouault at spatialys.com>
> wrote:
> > > This is a topic we already discussed a couple years ago. Please find a
> RFC
> > > about it in:
> > >
> > > https://github.com/OSGeo/gdal/pull/1984/files
> >
> > I dropped some comments there, not a review though.
>
> I've updated both the RFC and the implementation (number of changes since
> the
> preliminary one) to what I believe should be close to their final states.
>
> In addition to the rather dummy example of a Python driver that is in the
> RFC,
> there are 2 more interesting examples:
>
> * a PASSTHROUGH driver that forwards calls to the GDAL SWIG Python API:
>
> https://github.com/rouault/gdal/blob/pythondrivers/gdal/examples/pydrivers/ogr_PASSTHROUGH.py
>
> * a driver implemented a simple parsing of CityJSON (
> https://www.cityjson.org/)
>
> https://github.com/rouault/gdal/blob/pythondrivers/gdal/examples/pydrivers/ogr_CityJSON.py
>
> The tutorialshould also help:
>
> https://github.com/rouault/gdal/blob/pythondrivers/gdal/doc/source/tutorials/vector_python_driver.rst
>
> I'll submit the RFC to vote soon if there are no other remarks.
>
> Even
>

On the one hand, If I were a MapServer site administrator and it was my job
to render features from some special non-standard or proprietary format or
API as a layer on my maps and all it took was one Python file copied into a
directory on my server, I think I might like this feature. I feel like
there are already too many format drivers in GDAL/OGR and anything that
keeps a driver that only a handful of people will ever use out of the core
of the library is a good thing. On the other hand, I feel like these
plugins are a complicated solution to a problem that is pretty well solved
by running a format-specific python (or other language) program that writes
a stream of GeoJSON texts.

That said I have some comments that I hope will help refine the RFC.

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?

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_compilation.html#globally
.

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?

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?

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.

>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`?

-- 
Sean Gillies
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20191111/2e15198f/attachment-0001.html>