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

Cannot find proj.db when using C# Environment.SetEnvironmentVariable #1647

Closed
ktheijs opened this issue Jun 14, 2019 · 17 comments

Comments

@ktheijs
Copy link

commented Jun 14, 2019

Expected behavior and actual behavior.

I am using GDAL 3.0.0 in C# and I am encountering an issue regarding the new proj.db.
I set both the environment variable and the config option as shown here:
Environment.SetEnvironmentVariable("PROJ_LIB", <MyPath>);
Gdal.SetConfigOption("PROJ_LIB", <MyPath>);

However when I try to create a SpatialReference
SpatialReference spatialReference = new SpatialReference(csWkt);
I get the exception "PROJ: proj_create_from_wkt: Cannot find proj.db"

Is an additional step needed to make GDAL find the proj.db file?

Operating system

Windows 10

GDAL version and provenance

GDAL 3.0.0

@rouault

This comment has been minimized.

Copy link
Member

commented Jun 14, 2019

Is <MyPath> the name of the directory where proj.db is ?

@ktheijs

This comment has been minimized.

Copy link
Author

commented Jun 14, 2019

@rouault

This comment has been minimized.

Copy link
Member

commented Jun 14, 2019

is the environment variable set before you do any GDAL stuff ? As soon as GDAL has initialized PROJ, the variable might be ignored afterwards.

@ktheijs

This comment has been minimized.

Copy link
Author

commented Jun 14, 2019

@rouault

This comment has been minimized.

Copy link
Member

commented Jun 14, 2019

Can you enable PROJ_DEBUG=5 and report what appears in the standard error stream ?

@ktheijs

This comment has been minimized.

Copy link
Author

commented Jun 14, 2019

@ktheijs

This comment has been minimized.

Copy link
Author

commented Jun 17, 2019

I tried setting the variable like this
Gdal.SetConfigOption("CPL_DEBUG", "ON");
Gdal.SetConfigOption("PROJ_DEBUG", "5");

I'm not sure if the first line is necessary, but with or without it, I get no additional output in my error stream. Is this the right way to set this value?

@rouault

This comment has been minimized.

Copy link
Member

commented Jun 17, 2019

Ah, for PROJ_DEBUG and PROJ_LIB, they must be defined as operating system environment variables. GDAL config option concept only works for GDAL.

@ktheijs

This comment has been minimized.

Copy link
Author

commented Jun 17, 2019

Okay, good to know. I made the situation as simple as possible. And I still get the same issue.
This is the code that I am running at startup:
Environment.SetEnvironmentVariable("PATH", path);
Environment.SetEnvironmentVariable("PROJ_DEBUG", "5");
Environment.SetEnvironmentVariable("PROJ_LIB", projLibDirectoryFullName);
SpatialReference s = new SpatialReference("");
s.ImportFromEPSG(2353);

"path" is the correct path to set.
"projLibDirectoryFullName" points to the directory with the proj.db file.

This is the only relevant output I get (which is the same when I don't set the PROJ_DEBUG variable):

ERROR 1: PROJ: proj_create_from_database: Cannot find proj.db
Exception thrown: 'System.ApplicationException' in osr_csharp.dll

@szekerest

This comment has been minimized.

Copy link
Contributor

commented Jun 17, 2019

It looks like getenv doesn't seem to retrieve PROJ_LIB which has been set with Environment.SetEnvironmentVariable. According to https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/getenv-wgetenv?view=vs-2019 "getenv and _putenv use the copy of the environment pointed to by the global variable _environ to access the environment. getenv operates only on the data structures accessible to the run-time library and not on the environment "segment" created for the process by the operating system." We should probably find another way to specify the search location, using getenv is fragile because it depends on the time of the CRT initialization. Probably exposing OSRSetPROJSearchPaths would help.

@szekerest

This comment has been minimized.

Copy link
Contributor

commented Jun 17, 2019

Just tried exposing OSRSetPROJSearchPaths and it was working.
However it seems that proj is using that option as the last resort after trying to open a hardcoded proj_lib_name. It would be reasonable to test against search_paths in proj6 earlier or have GDAL to use other options (like setting the file_finder) to achieve the same result.

@ktheijs

This comment has been minimized.

Copy link
Author

commented Jun 18, 2019

Is there anything I can do for now, or should I wait until there is a fix released on your side?

@rouault

This comment has been minimized.

@rouault rouault changed the title Cannot find proj.db Cannot find proj.db when using C# Environment.SetEnvironmentVariable Jun 18, 2019

@szekerest

This comment has been minimized.

Copy link
Contributor

commented Jun 18, 2019

@rouault Yes, but I still can't imagine why the same approach was working with GDAL-2.4+proj4 and doesn't work with GDAL-3.0+proj6. Probably there has been a change how the proj lib is being loaded by GDAL?

@rouault

This comment has been minimized.

Copy link
Member

commented Jun 18, 2019

Probably there has been a change how the proj lib is being loaded by GDAL?

That depends on how GDAL was built in GDAL <= 2.4. If it wasn't built with -DPROJ_STATIC (and thus through LoadLibrary("proj.dll")), then yes, it might be a relevant difference. In GDAL 3.0, PROJ is always linked in a classic way to GDAL.

rouault added a commit to rouault/gdal that referenced this issue Jun 18, 2019

@rouault

This comment has been minimized.

Copy link
Member

commented Jun 18, 2019

#1658 shoud hopefully fix the issue by adding a osr.SetPROJSearchPath() method. I can't test C# , but at least that works for Python

@rouault rouault closed this in 94a03d0 Jun 19, 2019

rouault added a commit that referenced this issue Jun 19, 2019

Merge pull request #1658 from rouault/map_OSRSetPROJSearchPaths_to_SWIG
SWIG: add osr.SetPROJSearchPath(path) that can be used since setting PROJ_LIB from C# does no work (fixes #1647)

rouault added a commit that referenced this issue Jun 19, 2019

@rouault

This comment has been minimized.

Copy link
Member

commented Jun 19, 2019

I've merged #1658 in master and backported in release/3.0 as well. Search paths are taken into priority over PROJ_LIB or the hard-coded string (on Unix builds) starting with PROJ 6.1

@rouault rouault added this to the 3.0.1 milestone Jun 19, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
3 participants
You can’t perform that action at this time.