[gdal-dev] the /vsistdout mistery and the Update question

[Abel Pau]

Hi Even,
thanks for your answer.

ok with /vsistdout/

I’m sure trying to finish the job. I’ve been documenting that, going through actions errors. But I’m not trying to incorporate anything new but only trying to let it clean from doubts I have from the beginning and I left for later. Now is this later :)

Tests in windows are resisting to be passed because there are some problems with python and windows (I’m new al python) but I hope I can confront them from Monday.

Soon I’ll create the mentioned feature branch and I’ll put all modifications there and I’ll pool request.
I’m willing to do that!

Have a nice weekend


De: Even Rouault <even.rouault at spatialys.com>
Enviado el: divendres, 23 de febrer de 2024 16:50
Para: Abel Pau <a.pau at creaf.uab.cat>; gdal-dev at lists.osgeo.org
Asunto: Re: [gdal-dev] the /vsistdout mistery and the Update question


Abel,
Le 23/02/2024 à 10:34, Abel Pau via gdal-dev a écrit :
Hi,
after reading https://gdal.org/user/virtual_file_systems.html#vsistdout-standard-output-streaming I have to say I don’t understand what it means.

I which cases it’s used? Some example to consider?

/vsistdout/ also makes sense for formats that can be streamed in writing, that is you can generate the content as data flows in the driver and don't have to seek back to edit something in the header. So only a small subset of formats/drivers can natively support that. The canonical example is a CSV file. So I'd say don't worry about that use case for your driver.


On the other hand, I am confused about the Update concept.
My driver is capable of creating from zero a layer from other formats.
But I haven’t programmed the capacity to insert a feature in a pre-existent layer (I cannot simply add at the end of the file because de format description is a little more complicated).

Same thing as above. A lot of drivers can only create + add features in the newly features, but can't (at least easily) edit or append to an existing file. So just return nullptr when Open() is called with the update flag with a CPLError() message.

Something like

    if (poDS != nullptr && poOpenInfo->eAccess == GA_Update)
    {
        CPLError(CE_Failure, CPLE_OpenFailed,
                 "SDTS Driver doesn't support update.");
        delete poDS;
        poDS = nullptr;
    }

You have been in a "development black hole" for a long time now, so I'd suggest you limit the functionality to what you've already implemented, and make it in good shape for review. The more code, the harder & longer effort for reviewers. You can always add new functionality in follow-up pull requests once a base has already been integrated.

Even

--

http://www.spatialys.com

My software is free, but my time generally not.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20240223/16ebe7a2/attachment-0001.htm>