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

[Even Rouault]

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