Hi Howard, > I agree about the need for the feature, and I think it is a useful > addition, but I'll admit to being a bit concerned about the "native" > nomenclature. It allows us to incrementally add capability for stuff like > GeoJSON extensions without having to disrupt the entire API to support it. > > Because every OGR Feature implementation potentially has a native > representation, this API addition brings up some questions: > > 1) Would it be an ideal that every OGR feature carry around a blob of its > native representation to answer this API?
Not all formats have necessary a more expressive "native" representation than the one given by their OGRFeature. And this only makes sense when doing conversions between the same format. > 2) "Native" sounds faster or > better in some unspecified qualitative way, and this name might cause > people to go peeking into rabbit holes of the API that they might best > stay out of. I'm very well open to suggestions for a better naming... from English native speakers ;-) Sean initially proposed the note/annotation terminology. Your concerns can also perhaps be addressed by adding to the documentation of the related methods that this isn't intended for general use and only to gain access to details that cannot be expressed otherwise through the rest of the API ? > 3) Is there to be an ODCNative capability test for drivers? As Daniel suggested, maybe we need to be able to enable on purpose that capability as an open option. So the open option list could have a NATIVE_REPRESENTATION=YES/NO toggle (default NO). And perhaps have also a GDAL_DCAP_NATIVE_VECTOR metadata item at the driver level. Even -- Spatialys - Geospatial professional services http://www.spatialys.com _______________________________________________ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
