[gdal-dev] A question of eficiency

Fri Jul 21 10:37:42 PDT 2023

Ok,
It’s just what happened when I programmed the read-from-Spatial-Oracle and write-in-our-format.
Our format have a main header, one header for every feature (so, as many as features in the layer) and after that have the geometric information.
In other files have the other information that comes from Fields. No prblem in that one.

I can use a not efficient but simple strategy: write every part in separate files and put all together on the correct place after finishing.

Thanks a lot for answering!

Abel Pau Garcia
Tècnic en SIG
[cid:image010.png at 01D740ED.86C01100]
a.pau at creaf.uab.cat<mailto:a.pau at creaf.uab.cat>
Tel. +34 935814277
[cid:image011.png at 01D740ED.86C01100]

[cid:image012.png at 01D740ED.86C01100]<https://www.facebook.com/CREAFecologia/>[cid:image013.png at 01D740ED.86C01100]<https://twitter.com/CREAF_ecologia>[cid:image014.png at 01D740ED.86C01100]<https://www.linkedin.com/company/1363052?trk=tyah&trkInfo=clickedVertical:company,clickedEntityId:1363052,idx:2-1-2,tarId:1465807877789,tas:creaf>[cid:image015.png at 01D740ED.86C01100]<https://www.youtube.com/c/creafecologia>[cid:image016.png at 01D740ED.86C01100]<https://www.instagram.com/CREAF_ecologia/>
www.creaf.cat<http://www.creaf.cat> | http://blog.creaf.cat
[cid:image017.png at 01D740ED.86C01100]
CREAF. Campus UAB. Edifici C. 08193 Bellaterra (Barcelona)

Abans d'imprimir aquest missatge electrònic penseu en el medi ambient.

De: Even Rouault<mailto:even.rouault at spatialys.com>
Enviat: divendres, 21 de juliol de 2023 19:32
Per a: Abel Pau<mailto:a.pau at creaf.uab.cat>; gdal-dev at lists.osgeo.org<mailto:gdal-dev at lists.osgeo.org>
Tema: Re: [gdal-dev] A question of eficiency

Abel,

OK, I now better understand what you meant. Well, no, there's no way for the writing part of a driver to know how many features there are in the source layer, because in the general case, there is no source layer... Users could potentially call CreateFeature() without any source layer and without knowing in advance how many features they are going to write. Ideally your driver wouldn't need to know that, but I don't know the specificities of your format. If you really need to know the number of features before being able to write the file, the strategy would be that the ICreateFeature() method of your driver actually delegates writing those features to another GDAL driver (e.g GeoPackage) in a temporary file, and upon layer closing, you read back that temporary file to actually write your own file.

In some cases, ogr2ogr could potentially know in advance the number of features to be written and pass them to the output driver(as well as the extent typically), but:

- knowing the number of features can be a pretty slow operation for some input drivers , or when using a SQL statement

- and there's no such infrastructure currently

Even
Le 21/07/2023 à 19:23, Abel Pau a écrit :
Hello!

I’ve been trying to use the OGRLayer::GetFeatureCount() when I am reading another format inside the ICreateFeature() but I think it’s impossible. At this point I don’t have access to the layer info, so to the GetFeatureCount().
In fact I don’t mind where to call this function but I need to call it in order to write our format efficiently (at least in most of cases).

So the question is, in my driver, when I read a format I get some information about the layer but I can’t acces to the count of the features of the layer. I am right? If not, how I do that?

Thanks but before sending this mail I’ve been like hours trying to find it out debbuging and consulting the call stack from all points and nothing seems to indicate I can do that. But perhaps I am wrong.

It would be very helpful knowing that information. I not my writting strategy with change radically. Thankssssss!

De: gdal-dev <gdal-dev-bounces at lists.osgeo.org><mailto:gdal-dev-bounces at lists.osgeo.org> En nombre de Abel Pau
Enviado el: divendres, 7 de juliol de 2023 12:44
Para: Even Rouault <even.rouault at spatialys.com><mailto:even.rouault at spatialys.com>; gdal-dev at lists.osgeo.org<mailto:gdal-dev at lists.osgeo.org>
Asunto: Re: [gdal-dev] A question of eficiency

Hi again,

I can totally give this number in GetFeatureCount(). No problem from my driver to other.
Then I understand that in one way (efficient) or in another (no efficient) I can always get the number of features with the GetFeatureCount(). True?

About the other question imagine a multiline shape with two lines of two parts every line. I need to know the total count of individual lines (cause my driver doesn’t have multiline and I have to convert every multiline to N lines). It is 4 (2+2). Can I get this number without asking every feature how many parts it have? I doubt that, but...

Thanks for your kind anwser!

De: Even Rouault <even.rouault at spatialys.com<mailto:even.rouault at spatialys.com>>
Enviado el: divendres, 7 de juliol de 2023 12:32
Para: Abel Pau <a.pau at creaf.uab.cat<mailto:a.pau at creaf.uab.cat>>; gdal-dev at lists.osgeo.org<mailto:gdal-dev at lists.osgeo.org>
Asunto: Re: [gdal-dev] A question of eficiency

Abel,

At the minimum for the reading side of a vector driver, you need to implement GetNextFeature().

If there is an efficient way of knowing the number of features without iterating over the whole file (typically a field in a header giving that number), you may implement GetFeatureCount(). If you don't implement it, and code using your driver needs the feature count, the generic implementation of OGRLayer::GetFeatureCount() will call GetNextFeature() repeatdly until it returns NULL.

Not totally sure to understand your question about multielements. If you have an instance of OGRGeometryCollection or any deriving class, there's a getNumGeometries() method to get the number of parts

Even
Le 07/07/2023 à 11:33, Abel Pau a écrit :
Hi,
I would like to know if when we use the code of GDAL to program a driver (or whatever) in vectors (so, ogr) we can assume that we can know the number of elements we are going to import in any way or it would be possible not knowing that until NextFeature is empty (or something like that). So, there is any way to obtain this number of elements without doing a while? And in case of multielements its possible to know how many parts are there in total?
I need that to write my format (I don’t explain the details cause I don’t get you bored :) )

If anyone know that I’d appreciate an answer. Thanks in advance.

Abel.

_______________________________________________

gdal-dev mailing list

gdal-dev at lists.osgeo.org<mailto:gdal-dev at lists.osgeo.org>

https://lists.osgeo.org/mailman/listinfo/gdal-dev

--

http://www.spatialys.com

My software is free, but my time generally not.

--

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/20230721/b297af70/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0829C36EF5094B038A5550947359A8A3[3370034].png
Type: image/png
Size: 3936 bytes
Desc: 0829C36EF5094B038A5550947359A8A3[3370034].png
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20230721/b297af70/attachment-0008.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: AFB2D939202140B1A66CD97C55BA07F0[3370035].png
Type: image/png
Size: 4488 bytes
Desc: AFB2D939202140B1A66CD97C55BA07F0[3370035].png
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20230721/b297af70/attachment-0009.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 77F1D63BF16849EF8905B4E996CCDC7D[3370036].png
Type: image/png
Size: 940 bytes
Desc: 77F1D63BF16849EF8905B4E996CCDC7D[3370036].png
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20230721/b297af70/attachment-0010.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0B23853F311F49F498CBC28D2206E251[3370037].png
Type: image/png
Size: 930 bytes
Desc: 0B23853F311F49F498CBC28D2206E251[3370037].png
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20230721/b297af70/attachment-0011.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 5F72F8A7690D45638326CB3CFC331A3A[3370038].png
Type: image/png
Size: 936 bytes
Desc: 5F72F8A7690D45638326CB3CFC331A3A[3370038].png
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20230721/b297af70/attachment-0012.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: D1AD5E45B4D640BAAE3DCD090B1CF0C7[3370039].png
Type: image/png
Size: 980 bytes
Desc: D1AD5E45B4D640BAAE3DCD090B1CF0C7[3370039].png
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20230721/b297af70/attachment-0013.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 035E57EF07824665997D96FD07A833CC[3370040].png
Type: image/png
Size: 1053 bytes
Desc: 035E57EF07824665997D96FD07A833CC[3370040].png
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20230721/b297af70/attachment-0014.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 149ADE8446C8407A855709F762EA8AAC[3370041].png
Type: image/png
Size: 239 bytes
Desc: 149ADE8446C8407A855709F762EA8AAC[3370041].png
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20230721/b297af70/attachment-0015.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 8467D83278924230A35A48263882DC19[3370042].gif
Type: image/gif
Size: 1185 bytes
Desc: 8467D83278924230A35A48263882DC19[3370042].gif
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20230721/b297af70/attachment-0001.gif>