[gdal-dev] OGR csv driver: feature numbering
even.rouault at mines-paris.org
Sat Aug 27 06:25:19 EDT 2011
Le samedi 27 août 2011 12:07:12, Hermann Peifer a écrit :
> 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 ,
> 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 .
> 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.
More information about the gdal-dev