[gdal-dev] OGR csv driver: feature numbering
peifer at gmx.eu
Sat Aug 27 07:08:58 EDT 2011
On 27/08/2011 12:25, Even Rouault wrote:
> 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.
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
$ 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.
More information about the gdal-dev