@vpipkt Odd:

https://travis-ci.org/locationtech/rasterframes/builds/576845586#L962-L975

Still having some class not found errors in travis. Unsure why.

@vpipkt I think something's wrong with the implementation, because in this test case the scheme resolution should not be attempting to use the GDAL reader if it's not available, yet it's still selecting it over the default reader.

https://travis-ci.org/locationtech/rasterframes/builds/580393491#L832-L866

@vpipkt Not 100% sure what's going on here, but don't want to be extra sure the JVM fallback reader still gets selected in non-GDAL scenarios. Wonder if we should leverage this sort of logic?

Also odd: not seeing it here:

https://circleci.com/gh/s22s/rasterframes

Now you can see in Circle CI, it is passing. https://circleci.com/gh/s22s/rasterframes/tree/fix%2F314

@vpipkt Once this weirdness is resolved, should we be trying to use this (if memory serves, written by Azavea folk!)?:

https://gdal.org/user/virtual_file_systems.html#vsihdfs-hadoop-file-system

@metasim yep, by @jamesmcclain

@metasim yep, by @jamesmcclain

I am here to help if you run into any trouble with that. Please be advised that some users have run into issues when trying to access HDFS filesystems through GDAL from a JVM process. The problem appears to be related to the fact that GDAL spawns its own inferior JVM to interface with HDFS, and that is done from within a JVM process running native GDAL code (more here).

EDIT: Specifically, please see this comment and surrounding comments. There does not appear to be a problem on OpenJDK 11, but there is a problem with OpenJDK 8.

@jamesmcclain Thanks for the background color... sounds to me like we shouldn't go that route if we don't have to.

@jamesmcclain Thanks for the background color... sounds to me like we shouldn't go that route if we don't have to.

You are welcome. /vsiwebhdfs might still be an option for you, depending on what you are looking for.