[gdal-dev] Call for discussion on RFC 60: Improved round-tripping in OGR

[Sean Gillies]

Howard, Even,

On Tue, Oct 20, 2015 at 2:59 AM, Even Rouault <even.rouault at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20151021/5948e645/attachment.html>