[gdal-dev] OGR csv driver: feature numbering

[Hermann Peifer]

On 27/08/2011 12:25, Even Rouault wrote:
> Le samedi 27 août 2011 12:07:12, Hermann Peifer a écrit :
>> Hi,
>>
>> I am just wondering why the csv driver starts numbering at 1, rather
>> than at 0, see e.g. the "First point" in the test.csv example at [1],
>> which ends up as OGRFeature(test):1.
>>
>> However, if I take the test.vrt/test.csv example and convert it to
>> shapefile format, I end up with features 0, 1 and 2, see [2].
>>
>> Is this how it should be?
>
> AFAIK, there is no convention imposed by the OGR model on how numbering should
> be done and the current situation depends much of the mood of the driver
> authors when they coded it.
>
> I want to draw your attention that, pedantically speaking, this number is not
> a sequence number, but a feature ID, with no guarantee that it is sequential
> when iterating over the features. For shapefiles or database drivers, you can
> have holes in the numbering due to deleted features. For database drivers when
> issuing a SQL request, the features can also even be returned in random order
> w.r.t to their feature ids.
>
> But I agree it would have been good to behave consistently in the case of no
> holes. Not sure if it is worth changing that now and potentially causing
> issues to people (wrongly) relying on how the numbering is currently done.

Even,

Thanks once again for your quick reply. I just came across when trying 
to get the first point from a csv file into a shapefile, using something 
like:

$ ogr2ogr test.shp test.vrt -where fid=0

The resulting shapefile was empty, to my surprise. I see that the kml 
driver also starts numbering at 1. I do agree that it might not be worth 
changing the current, somewhat inconsistent behaviour.

Hermann