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
_______________________________________________
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
