[QGIS-Developer] QGIS/OGR: FeatureIds reassigned on write to data provider?
Even Rouault
even.rouault at spatialys.com
Thu Jul 6 01:57:08 PDT 2017
On jeudi 6 juillet 2017 10:45:21 CEST Sandro Mani wrote:
> On 05.07.2017 14:56, Sandro Mani wrote:
> >> That could potentially be done using the current OGR API. Basically
> >> in pseudo code, to execute before executing REPACK
> >>
> >> OGR_L_ResetReading(layer)
> >>
> >> char** ignored_fields = CSLAddString(NULL, "OGR_GEOMETRY" );
> >>
> >> OGR_L_SetIgnoredFields( layer, ignored_fields); // for performance.
> >>
> >> CSLDestroy(ignored_fields);
> >>
> >> OGR_L_SetAttributeFilter( layer, NULL )
> >>
> >> OGR_L_SetSpatialFilter( layer, NULL )
> >>
> >> std::map<GIntBig, GIntBig> mapOldIdToNewId;
> >>
> >> GIntBig newId = 0;
> >>
> >> while( feature = OGR_L_GetNextFeature(layer) )
> >>
> >> {
> >>
> >> mapOldIdToNewId[OGR_F_GetFID(feature)] = newId;
> >>
> >> newId ++;
> >>
> >> OGR_F_destroy(feature);
> >>
> >> }
> >>
> >> OGR_L_SetIgnoredFields( layer, NULL );
> >
> > Ok cool, that sounds like a plan - I'll give it a shot.
>
> Hmm so while on the provider side it works well, for the geometry
> checker it is turning out to be pretty hard to deal with the changing
> feature ids (just to cite one example: error fixed by merging geometry
> of feature 10 with that of 11, results in {deleted: 10, updated: 11},
> but after the feature id adjustment this would read {deleted: 10,
> updated: 10}, meaning one would need to keep track that deleted: 10
> refers to the old featureid). Not saying that it isn't doable, but the
> complexitiy of properly handling the feature id changes is non-trivial.
>
> So, other suggestion: any objections if I add a method to
> QgsVectorDataProvider to temporarily freeze repacking? I could also add
> a notification informing the user that the shapefile should not be used
> in other applications while repacking is frozen.
My feeling is that QgsOgrDataProvider is already complicated enough with its existing tricks.
I'm not sure this temporary freeze repacking is a right move (how would you decide when you
do it ? and I'm pretty sure users will not get it, or will have issues if they start an algorithm
with an external tool that requires packed shapefiles)
I can understand the non-triviality of managing the feature id changes in the plugin, but it
seems to me to be safer overall.
Even
--
Spatialys - Geospatial professional services
http://www.spatialys.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20170706/f829d80a/attachment.html>
More information about the QGIS-Developer
mailing list