[gdal-dev] OGR csv driver: feature numbering

[Even Rouault]

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.