/vsi support

[andrewharvey]

The /vsicurl and /vsis3 options aren't working for me, is this a known issue or likely some issue on my end?

gdal.open('/vsicurl/http://localhost:8000/file.tiff')

gives

Error: Error opening dataset

[yocontra]

@andrewharvey It isn't in the list of supported formats in the README at the moment - now that this repository has been updated and cleaned up I don't think it should be too hard to add support for that.

[ekulno]

This would be very helpful for my use-case as well, where I need to process a large number of small pieces of data one-by-one. I believe VSI support would allow me to do this without needing to write to temporary files.

[mmomtchev]

@Ysgorg VSI support is enabled, it is curl and S3 that are missing
@andrewharvey
Both depend on compiling against libcurl, so you will kill two birds with one stone
The magic happens in deps/libgdal/libgdal.gyp, the GDAL define is HAVE_CURL
And curl is already present on the build system

[mmomtchev]

In fact, I am afraid that this is a substantial project.
node-gdal has a policy of being self-sufficient, ie not taking any libraries from the build machine
This means that we will have to include not only libcurl itself - but also Openssl, Libssh2, nghttp2, Zlib, cares, brotli and NASM
And most of these have very special build requirements for Windows
@andrewharvey @Ysgorg
What I suggest is that you simply build against your OS-provided/built-from-sources GDAL with --shared_gdal

[mmomtchev]

I spent some this researching this issue, and I can definitely say that you should not hold your breath for libcurl support in node-gdal
It is a pity, since c-ares, Zlib, Openssl, nghttp2 and NASM are dependencies of Node and are already included
However compiling against those, which are not publicly exported, is a very tricky task - especially since their own versions change across different Node versions - this is the very reason for the existence of NAN and N-API - to allow for third-party native modules to compile and link against a fixed and permanent Node ABI
The living proof of this is the node-curl project - this is a wrapper around libcurl - they have two very complex build systems -one for Linux/OSX and one for Windows and they have to include separate versions of all those dependencies per Node version as they always need to match exactly those that are already included in Node

Rebuilding node-gdal-next against your own shared GDAL library with --shared_gdal is the way to go

[iSkore]

@mmomtchev Would you mind posting an example of this?
Or would it just be npm install gdal-next --build-from-source --shared_gdal?

[yocontra]

@iSkore Yep npm install gdal-next --build-from-source --shared_gdal is correct.