Howard, Even, On Tue, Oct 20, 2015 at 2:59 AM, Even Rouault <even.roua...@spatialys.com> wrote:
> 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 ? > I like the format-native data concept, but agree that there's some potential for confusion. For GeoJSON, the native data could also be accurately called "extension data". How about that? ... -- Sean Gillies
_______________________________________________ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
