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

2024-02-23 Thread Abel Pau via gdal-dev 
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 
Enviado el: divendres, 23 de febrer de 2024 16:50
Para: Abel Pau ; gdal-dev@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.
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

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

2024-02-23 Thread Even Rouault via gdal-dev 

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.
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev