[Qgis-developer] Memory data provider persistence

[Even Rouault]

Le mercredi 25 juillet 2012 20:03:16, Chris Crook a écrit :
> Hi .. yes I don't like masking the FID field and I'm not thinking this is a
> long term solution, even before the problem in my implementation with the
> field index issue (which I think I will be able to fix).  I'm looking at a
> couple of options over the next few days .. and open to any contributions,
> suggestions, code, etc :-)

Chris,

did you try setting GML_EXPOSE_FID to NO before opening the GML as we 
discussed on the GDAL trac system ? This should fix your issue without much 
code, basically calling CPLSetConfigOption("GML_EXPOSE_FID", "NO") (or 
gdal.SetConfigOption("GML_EXPOSE_FID", "NO") if you're coding in Python) before 
doing the OGROpen() call with the GML file.

Actually, to avoid "polluting" other portions of code, you should save the 
original value and restore it afterwards, so :

in C/C++ :

char* pszOldVal = CPLGetConfigOption("GML_EXPOSE_FID") ? 
strdup(CPLGetConfigOption("GML_EXPOSE_FID")) : NULL;
CPLSetConfigOption("GML_EXPOSE_FID", "NO");
OGRDataSource hDS  = OGROpen(....);
CPLSetConfigOption("GML_EXPOSE_FID", pszOldVal);
free(pszOldVal);

in Python :

old_val = gdal.GetConfigOption("GML_EXPOSE_FID")
gdal.SetConfigOption("GML_EXPOSE_FID", "NO")
ds = ogr.Open(....)
gdal.SetConfigOption("GML_EXPOSE_FID",old_val)

And to avoid confusion, yes, you should also avoid that a user creates a 'FID' 
field.

> 
> Cheers
> Chris
> ________________________________________
> From: haubourg [regis.haubourg at eau-adour-garonne.fr]
> Sent: 23 July 2012 20:58
> To: qgis-developer at lists.osgeo.org
> Subject: Re: [Qgis-developer] Memory data provider persistence
> 
> Hi Chris, thanks for your feedback. I start thinking using a spatialite is
> a great idea. I prefer this than having rules to mask FID field. This can
> generate very hard-to-find bugs..
> 
> Having a complex Qgs zipfile containing either a spatialite DB or xml +
> data would be great but is a big evolution. IMHO, such a break should be
> kept for a major version change in QGIS (2.0?).
> 
> Is that a work you are on ? Need contributors?
> 
> 
> 
> 
> 
> 
> --
> View this message in context:
> http://osgeo-org.1560.n6.nabble.com/Memory-data-provider-persistence-tp410
> 8012p4989995.html Sent from the Quantum GIS - Developer mailing list
> archive at Nabble.com.
> 
> This message contains information, which is confidential and may be subject
> to legal privilege. If you are not the intended recipient, you must not
> peruse, use, disseminate, distribute or copy this message. If you have
> received this message in error, please notify us immediately (Phone 0800
> 665 463 or info at linz.govt.nz) and destroy the original message. LINZ
> accepts no responsibility for changes to this email, or for any
> attachments, after its transmission from LINZ. Thank You.
> _______________________________________________
> Qgis-developer mailing list
> Qgis-developer at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/qgis-developer