yocontra / node-gdal-next

Node.js bindings for GDAL (Geospatial Data Abstraction Library) [Fork]
https://contra.io/node-gdal-next/
Apache License 2.0
75 stars 36 forks source link

Cannot find proj.db #2

Closed claustres closed 3 years ago

claustres commented 4 years ago

Thanks for this fork as we are happy trying to migrate some of our projects on Node v12 !

For instance https://github.com/weacast/weacast-gtiff2json seems to work well.

However we have an issue migrating https://github.com/kalisio/krawler where we use the GDAL binding to perform coordinates transformation. In that case, when upgrading to your fork then running our tests, we get this error: Error: PROJ: proj_create_from_database: Cannot find proj.db.

As we did not have this issue previously I wonder if this is related to some setup we need to update like GDAL_DATA or PROJ_LIB or to your package directly.

Thanks again for your feedback.

yocontra commented 4 years ago

@claustres What OS are you having the issue on? We set the env var here by default which should get picked up by gdal https://github.com/contra/node-gdal-next/blob/master/lib/gdal.js#L22 but I have heard mixed messages that this may not work on windows. All of the CI tests pass on windows though, so really not sure.

Also - make sure you're on the latest version - I fixed an issue with that env var not being set correctly in one of the earlier patch releases.

claustres commented 4 years ago

Yes I am using Node.js 12 under Windows 10, we also have a travis build under Linux which seems to be fine, so this could be related. I think we use the last version already (1.0.2).

yocontra commented 4 years ago

@claustres Hmm... Can you try to manually set the env var to this value https://github.com/contra/node-gdal-next/blob/master/lib/gdal.js#L7 and see if that fixes it? If so we can confirm it is an env issue on windows and I can look into a fix for it.

claustres commented 4 years ago

Sorry for the delay, just tested this morning and I confirm this fixes the issue.

yocontra commented 4 years ago

This might be a tricky one to fix - I don't have any ideas off the top of my head. We can't build this in at compile because the relative path isn't the same at build time and install time, but also can't use ENV to set it.

One kind of messy option is to add a function into PROJ for manipulating it programmatically (similar to how this works in GDAL for setting GDAL_DATA), so we have that on the table. I would prefer not do to that because it's one more patch to keep maintained when updating libroj.

claustres commented 4 years ago

I don't see it as a bug, the docs should maybe just specify that under Windows or some cases you need to set the env var manually.

yocontra commented 4 years ago

@claustres Were you able to set the env to a relative path? Could you paste the value and I'll add it to the docs until we have a workaround.

claustres commented 4 years ago

No I used an absolute path, what is strange is that if I remove my env var and console.log the env var when launching my module it is still set so that your module is correctly changing it, and the path is absolutely the same than the one I set in the env var. Maybe it is related to the initialization order and some operation requires the env var before it is correctly set ?

yocontra commented 4 years ago

@claustres The issue is that ENV isn't able to be set by node (in windows only) in a way that the native C code can access it - the value is changed within the node context but nowhere else.

claustres commented 4 years ago

ok got it, some docs update seems the way to go ;-)

olivierchatry commented 3 years ago

One way would be to directly call OSRSetPROJSearchPaths and not rely on the PROJ_LIB environment variable in case the built-in version of gdal is used ?

olivierchatry commented 3 years ago

Added a pull request https://github.com/contra/node-gdal-next/pull/32 @contra if you want to take a look.