You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We currently call proj_context_set_search_paths in __init__ to make it find the share/proj data that always comes with PROJ_jll. However if proj_context_set_search_paths is used then it doesn't look further down the documented location order: "If set, the next tests will not be run." I'm assuming that means it will stop there, whether the file is found or not.
We probably don't need to call proj_context_set_search_paths in __init__ since the artifact uses the standard prefix layout so it should find it relative to the shared library at ../share/proj/. A benefit of not using it is that we will be open to users setting PROJ_DATA, as well as looking in the PROJ user writable directory. Otherwise it needs to be explicitly added by users getting grids, as in #75 (comment).
It can also be a conscious decision to keep the call to proj_context_set_search_paths in __init__ to isolate Proj.jl from system wide configuration settings, as it is now. I'm not sure how easy or common it is to break things based on these settings however. Though I'm not really looking forward to debugging user issues related to unintentional system wide configurations.
If we want to keep things isolated from system wide settings by default, we should have a good julia specific location to write grids to with projsync. One option worth looking into would be to use https://github.com/JuliaPackaging/Scratch.jl for this, and then during __init__ add that to the search path: Proj.proj_context_set_search_paths(2, [Proj.PROJ_DATA[], scratch_dir]). This does allow it to find grids you downloaded in previous julia sessions to the scratch dir, and any julia-specific bad resource state can be wiped using clear_scratchspaces!(Proj).
The text was updated successfully, but these errors were encountered:
This refers to the docs at https://proj.org/resource_files.html#where-are-proj-resource-files-looked-for.
We currently call
proj_context_set_search_paths
in__init__
to make it find theshare/proj
data that always comes with PROJ_jll. However ifproj_context_set_search_paths
is used then it doesn't look further down the documented location order: "If set, the next tests will not be run." I'm assuming that means it will stop there, whether the file is found or not.We probably don't need to call
proj_context_set_search_paths
in__init__
since the artifact uses the standard prefix layout so it should find it relative to the shared library at../share/proj/
. A benefit of not using it is that we will be open to users settingPROJ_DATA
, as well as looking in the PROJ user writable directory. Otherwise it needs to be explicitly added by users getting grids, as in #75 (comment).It can also be a conscious decision to keep the call to
proj_context_set_search_paths
in__init__
to isolate Proj.jl from system wide configuration settings, as it is now. I'm not sure how easy or common it is to break things based on these settings however. Though I'm not really looking forward to debugging user issues related to unintentional system wide configurations.If we want to keep things isolated from system wide settings by default, we should have a good julia specific location to write grids to with
projsync
. One option worth looking into would be to use https://github.com/JuliaPackaging/Scratch.jl for this, and then during__init__
add that to the search path:Proj.proj_context_set_search_paths(2, [Proj.PROJ_DATA[], scratch_dir])
. This does allow it to find grids you downloaded in previous julia sessions to the scratch dir, and any julia-specific bad resource state can be wiped usingclear_scratchspaces!(Proj)
.The text was updated successfully, but these errors were encountered: