Hi Nicolas, > Hi list, > > I'm a little disappointed because I have hoped to find in version 2 a > reinforcement (unification) of the semantics of operations against the > reported capabilities (cf OGRLayer.TestCapability)
Apart from the below example, are you thinking to other things ? RFC 46 is already big enough, and I'd prefer it not to turn into a jumbo RFC ;-) > > For exemple, if I take the function OGRLayer.SetFeature (OGRFeature * > poFeature) which is documented as âRewrite an existing featureâ > I found drivers implementing it with âupdate/whereâ which do nothing if > feature does not exist (conforming implementation), > and other drivers implementing it with âdelete/insertâ which always > insert the feature (not conforming implementation) I'd say that it is pretty much an implementation detail that could/should be fixed in the drivers, if it can be. Which drivers are you thinking to that would not implement the right semantics ? > > I think that adopting the same semantic will allow to automate generic > autotests on the basis of reported capabilities (and simplify autotest). > This will also simplify applications that want to use GDAL/OGR in a generic > way There's already the test_ogrsf utility that can be used for that. A substantial number of OGR drivers already include a test that run it. > > In addition, these generic autotests could allow developers to validate the > compatibility of their new driver against the semantics of GDAL/OGR and can > give a kind of âcompatibility labelâ. Yes, but some manual tests are still necessary because test_ogrsf will not be able for example to tell if the values of features reported by the drivers are the one expected. It can only do consistency checks, like checking that the number of iterations of GetNextFeature() equals to GetFeatureCount(), etc... > > May be this suggestion becomes a new RFC (if someone else agree with me) If someone wants to do the implementation work ;-) But I'm still not clear on the scope you would give to such an RFC. Regards, Even _______________________________________________ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
