CoordinateTransformation error

[GretaCB]

Are you familiar with the following error?
CoordinateTransformation parameter already destroyed

Error is triggered by this line: https://github.com/mapbox/mapnik-omnivore/blob/raster/lib/datasourceProcessor.js#L332

It's an odd error because it works fine within my application, but throws in Travis when tests are running.

I can't find much on it in GDAL documentation or basic web search. I found it commented out in node-gdal here: https://github.com/naturalatlas/node-gdal/blob/master/src/gdal_common.hpp

Interested if you've run into this before or have any thoughts on what could be throwing it. Thanks!

[brandonreavis]

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.

[brandonreavis]

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

[GretaCB]

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.

[brandonreavis]

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.

[brandonreavis]

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.

[springmeyer]

@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.

[GretaCB]

Woot! Error averted in Travis with the new commit.

[brianreavis]

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).

[springmeyer]

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.

[brianreavis]

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?

[brianreavis]

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.