Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

GDAL_DATA not set #49

Closed
yeesian opened this issue Jun 30, 2018 · 6 comments
Closed

GDAL_DATA not set #49

yeesian opened this issue Jun 30, 2018 · 6 comments

Comments

@yeesian
Copy link
Member

yeesian commented Jun 30, 2018

Still receiving the following error message:

Unable to open EPSG support file gcs.csv. Try setting the GDAL_DATA environment variable to point to the directory containing EPSG csv files.

log here: https://travis-ci.org/yeesian/ArchGDAL.jl/jobs/398597673#L749

@yeesian
Copy link
Member Author

yeesian commented Jun 30, 2018

see #30 for previous discussion

@evetion
Copy link
Member

evetion commented Jul 3, 2018

Encountered the same here, will try to look for a fix next week.

visr added a commit to yeesian/ArchGDAL.jl that referenced this issue Jul 6, 2018
this seems to fix GDAL_DATA issues reported in JuliaGeo/GDAL.jl#49
@visr
Copy link
Member

visr commented Jul 6, 2018

I tried to look into this a bit, no fix (oh found it, see end of post), but perhaps some useful data points.

GDAL.jl sets GDAL_DATA in __init__ .

GDAL.jl/src/GDAL.jl

Lines 72 to 74 in 45a9c2e

# set the GDAL_DATA variable
GDAL_DATA = abspath(@__DIR__, "..", "deps", "usr", "share", "gdal")
ccall(fconf, Void, (Cstring, Cstring), "GDAL_DATA", GDAL_DATA)

To test if this works we have this test. If you stop setting the GDAL_DATA in __init__, and don't have it set in your env. vars., it fails, meaning the test works as intended.

GDAL.jl/test/runtests.jl

Lines 25 to 26 in 45a9c2e

srs = GDAL.newspatialreference(C_NULL)
GDAL.importfromepsg(srs, 4326) # fails if GDAL_DATA is not set correctly

When ArchGDAL starts it also runs GDAL.jl __init__, which I checked by adding this to the end of the __init__:

info("GDAL.jl set GDAL_DATA to ", GDAL_DATA)

But somehow this is not good enough, because running the same test from ArchGDAL fails. Instead of setting the config option via ccall, it also works to replace it in GDAL.jl with:

ENV["GDAL_DATA"] = GDAL_DATA

For ArchGDAL this still doesn't work, even though it can see the modified ENV from there.

The only thing that works so far is setting the GDAL_DATA environment variable yourself globally, which is something I hope to avoid telling users to do.

I even tried to set the GDAL_DATA via ccall by making a new __init__ function in ArchGDAL:

function __init__()
	ccall((:CPLSetConfigOption, GDAL.libgdal), Void, (Cstring, Cstring), "GDAL_DATA", GDAL.GDAL_DATA)
	info("ArchGDAL.jl set GDAL_DATA to ", GDAL.GDAL_DATA)
end

But even though it is running:

INFO: GDAL.jl set GDAL_DATA to C:\Users\visser_mn\.julia\v0.6\GDAL\deps\usr\share\gdal
INFO: ArchGDAL.jl set GDAL_DATA to C:\Users\visser_mn\.julia\v0.6\GDAL\deps\usr\share\gdal

It doesn't work. Whyyyyy?
Didn't check anything on julia nightly yet, but is worth trying.

Oh wait, just noticed that ArchGDAL doesn't __precompile__() whilst GDAL does. It works in all 3 other combinations... Odd. I guess that the __init__ ran after ArchGDAL was loaded or something?

I just added enabling __precompile__() and reenabling the test to yeesian/ArchGDAL.jl#48. Nothing to do here it seems :)

@visr
Copy link
Member

visr commented Jul 6, 2018

Hmm CI doesn't think adding __precompile__() to ArchGDAL is enough, even on Windows. Locally that seemed to be it... Maybe good to get it running on 0.7 (with depwarns) first to check if the issue is the same there.

@evetion
Copy link
Member

evetion commented Jul 6, 2018

I encountered it on GDAL.jl, not using ArchGDAL at all. Maybe these are separate issues? For me it has to do with multiple processes:

using GDAL
GDAL.importfromepsg(GDAL.newspatialreference(C_NULL), 4326)  # works
pmap(x->GDAL.importfromepsg(GDAL.newspatialreference(C_NULL), x), 4326:4330)  # fails

@visr
Copy link
Member

visr commented Jul 6, 2018

Wouldn't be surprised if they are actually the same. Let's try and see!

EDIT: They aren't, see #50 for fix of the above issue. And as a workaround for ArchGDAL.jl, try setting GDAL_DATA as environment variable.

visr added a commit that referenced this issue Jul 8, 2018
setting ENV["GDAL_DATA"] is better since it also works for parallel processes, see #49
@visr visr closed this as completed in #50 Jul 8, 2018
@visr visr reopened this Jul 8, 2018
yeesian added a commit to yeesian/ArchGDAL.jl that referenced this issue Jul 10, 2018
* update for latest version of gdal.jl

* don't throw away test files

people who test will want to keep them anyway, and people who don’t
won’t be bothered by the bloat

* fix travis script

* remove projection tests for now

* delete empty test REQUIRE

* add master testset

this will give aligned and more compact printing of test results

* remove workarounds

* remove unnecessary checknull

* precompile

this seems to fix GDAL_DATA issues reported in JuliaGeo/GDAL.jl#49

* add Compat to REQUIRE

* use Base.Dates

This works on 0.6, on 0.7 it should be `use Dates`, but this is needed to get around this error in 0.7:
UndefVarError: Date not defined

* fix UndefVarError on 0.7

* make tests more robust
@visr visr closed this as completed in 4371d12 Aug 1, 2018
visr added a commit to yeesian/ArchGDAL.jl that referenced this issue Aug 1, 2018
yeesian pushed a commit to yeesian/ArchGDAL.jl that referenced this issue Aug 2, 2018
* enable tests after fixing GDAL_DATA issue

JuliaGeo/GDAL.jl#49

* use Cstring as in GDAL

like JuliaGeo/GDAL.jl#47

without this I received errors like:
```
MethodError: no method matching unsafe_convert(::Type{Ptr{Cstring}}, ::Base.RefValue{Ptr{UInt8}})
```
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants