CoordinateTransformation error about node-gdal HOT 11 CLOSED

Interesting...

It seems like creating the coordinate transformation silently failed. It should be (but it's not yet) throwing an error in the CoordinateTransformation constructor if that happens.

https://github.com/naturalatlas/node-gdal/blob/master/src/gdal_coordinate_transformation.cpp#L60

I think the new CoordinateTransformation() is failing due to something like this (link) where proj4.dll isn't found on Travis. I'll need to look into it more, but if you call gdal.verbose() before maybe this error will show up?

ERROR 6: Unable to load PROJ.4 library (proj.dll), creation of OGRCoordinateTransformation failed.

from node-gdal.

This has got to be the issue... @brianreavis is looking into statically linking the proj4 library now.

from node-gdal.

I gave it a try by adding gdal.verbose(); before the line that is throwing the error, but nothing. Same output in Travis. Trying to figure out how to install proj.4 into Travis to see if that wipes the error.

from node-gdal.

Weird. Hold off a bit on that... we should be building proj.4 into node-gdal so that you shouldn't have to go out and install it.

from node-gdal.

That proj.4 error is showing up in travis here:
https://travis-ci.org/mapbox/mapnik-omnivore/builds/28452441#L9357

With the latest commits it will be a properly thrown error.

I was also able to reproduce the error by removing /usr/lib/libproj.so from my system. Tonight we should have node-gdal modified so that it doesn't need to go out and look for that library.

from node-gdal.

@brandonreavis nice work - my sense is the same - that you'll need to both statically link libproj.a and define -DPROJ_STATIC in the gyp files. After that you'll also need to set PROJ_LIB to point at projs' epsg files to support the +init=epsg:... syntax.

from node-gdal.

Woot! Error averted in Travis with the new commit.

from node-gdal.

Noice!

@springmeyer I haven't set PROJ_LIB to the folder containing the EPSG files yet. Do you have any thoughts on how we can make a test that fails before trying to set PROJ_LIB at runtime? The current coordinate transform tests are here, and they include some +init=epsg: transforms (which seem to work, strangely).

from node-gdal.

Try setting PROJ_LIB to something bogus and they should fail. I presume they are passing for you because the default PROJ_LIB path is burned into the binaries when you build and nothing has moved. Another test would be to move your working directory to some different path and then run the tests again. If things still pass is may be because the proj files are actually getting picked up from /usr/local/share/proj/epsg of something.

from node-gdal.

I just did some investigating on the PROJ_LIB situation. The weird thing is: no matter what I try, I can't get the test to break (awesome, but not awesome). What I've tried:

1. Uninstalled Proj.4 from my machine.
2. Compiled with -DPROJ_LIB=""
3. Set the PROJ_LIB environment variable to something bogus.
   export PROJ_LIB=~ && node_modules/.bin/mocha test
4. Modified pj_open_lib to always return NULL.
5. Ran the tests from another directory.

Am I missing something here? Is there something off about the +init=epsg: transform test?

from node-gdal.

Closing this. We can re-open if we manage to repro it, but for now I'm going to assume it's a non-issue.

from node-gdal.