gdal.config

[jdesboeufs]

Hi,

To open a shapefile with a specific encoding, we have to set SHAPE_ENCODING through gdal.config.set().

But after that, we are not able to reset this configuration to its original state, allowing other shapefile encodings to be auto-detected. It could be useful to have an option to unset a config variable, or maybe a config contexte bound to the dataset, and not GDAL itself.

WDYT?

[yocontra]

Yeah that makes sense to me - I think adding an unset function, and being able to set it per function call would be the best move. It could be done easily in the JS portion of the project to avoid massive amounts of C++ changes, and unset would be added in C++ - want to send a PR?

[jdesboeufs]

I've found a work-around: gdal.config.set('VAR', undefined). It seems to work.

Yes I agree. It could be interesting to have some helpers like this. OK to send a PR if this work-around is good or if we can have an unset function.

[yocontra]

I think unset or reset would be a fine API addition, and we can do a secondary PR to add a new helper.

Something like this could work? Pretty simple and flexible - would be much easier than adding a new config option to every single function

gdal.config(tempConfigObject, () => {
  // any gdal code here!
})

which would basically just be:

gdal.config = (obj, fn) => {
  const currentValues = gdal.config.get()
  const split = Object.entries(obj)
  split.forEach(([ k, v ]) => gdal.config.set(k, v))
  fn()
  split.forEach(([ k, v ]) => gdal.config.set(k, currentValues[k])
}

[mmomtchev]

@contra, that could work, just don't do it with the gdal.config object which is C++ backed, choose any other name @jdesboeufs when it comes to implementing this in C++, I am afraid it will require a very significant effort for a feature that can easily be reproduced in JS In fact, gdal.config.set() and gdal.config.get() are simply wrappers around the GDAL-provided functions CPLSetConfigOption() and CPLGetConfigOption() - which do not have any other functionality. In C++, GDAL has another set of functions, CPLSetThreadLocalConfigOption() and CPLGetThreadLocalConfigOption(), which do exactly what you want, but these are unusable from Node.js where the event loop is handled by libuv which provides the thread management - in fact when calling GDAL you have absolutely no control over which thread is going to call it