tiler won't write tiles

[jebyrnes]

I'm having the oddest issue. I'm running even the demo code to write out to a directory on a server. And yet, while it even will create the directory, it never ever writes files to the directory, and no error or warning messages are given. Not even sure how to debug this one...

[jebyrnes]

Re-installed gdal for python, and now I get a segfault! HA

sh: line 1: 60605 Segmentation fault      python "/home/jb92b/R/x86_64-pc-linux-gnu-library/3.5/tiler/python/gdal2tilesIMG.py" --leaflet -p raster -z 2-3 -w none --tmpdir "/tmp/RtmpGvaBZ3/g2ttmp" "/home/jb92b/R/x86_64-pc-linux-gnu-library/3.5/tiler/maps/map.png" "/project/tiler/tiles" 2> /dev/null

SessionInfo:

R version 3.5.1 (2018-07-02)
Platform: x86_64-pc-linux-gnu (64-bit)
Running under: Red Hat Enterprise Linux Server release 6.9 (Santiago)

Matrix products: default
BLAS: /share/pkg/R/3.5.1_gcc8.1.0/lib64/R/lib/libRblas.so
LAPACK: /share/pkg/R/3.5.1_gcc8.1.0/lib64/R/lib/libRlapack.so

locale:
 [1] LC_CTYPE=en_US.UTF-8       LC_NUMERIC=C              
 [3] LC_TIME=en_US.UTF-8        LC_COLLATE=en_US.UTF-8    
 [5] LC_MONETARY=en_US.UTF-8    LC_MESSAGES=en_US.UTF-8   
 [7] LC_PAPER=en_US.UTF-8       LC_NAME=C                 
 [9] LC_ADDRESS=C               LC_TELEPHONE=C            
[11] LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C       

attached base packages:
[1] stats     graphics  grDevices utils     datasets  methods   base     

other attached packages:
[1] stringr_1.3.1 raster_2.8-4  sp_1.3-1      tiler_0.2.1  

loaded via a namespace (and not attached):
[1] compiler_3.5.1   magrittr_1.5     tools_3.5.1      Rcpp_1.0.0      
[5] stringi_1.2.4    codetools_0.2-16 grid_3.5.1       png_0.1-7       
[9] lattice_0.20-38 

Using python 2.7.14. gdal 2.4.0

Thoughts?

[leonawicz]

Hi, thanks for the feedback. Can you confirm that your PR allows you to log helpful information regarding your issue?

I tested it out, but I have no errors to log. I can't remember why I originally put in to ignore std error in the system call. I'd be more inclined to remove that internal argument than to add the optinal argument to tile. Thoughts?

Do you think there are any circumstances where it would log anything and the user wouldn't want to see it? I may have left that internal argument in there by accident during my own testing last year. I honestly can't remember why it's there and set to TRUE. If you want to just remove it from the system call instead, I can merge an updated PR in instead. Let me know if you think the option is really necessary.

For now I don't have a way to test based on your system setup. All I can say is in the past anytime I ran tile and it executed but created no tiles, it was because I was failing to find the Python path (Or OSGeo4W on Windows). I'd like to have it throw an exception if the system resources are not found, generally on Linux, Windows or Mac, instead of returning silently as it does now. But I also need to resolve that issue in conjunction with issue #6

[jebyrnes]

So, I discovered the utility of this stepping through the function line by line to find the writing problem. When I changed the option to TRUE, I got back relevant errors. Removing it would work as well. Whatever you think works better. Perhaps this will also help with your related issue? FYI, it was because R was calling a different version of python than I had gdal installed for. Once I installed gdal on my desktop, it was smooth sailing.

[jebyrnes]

However, the segfault is a different issue, I think. And it's running on a different computer (server). Would love any thoughts on that. I can also open a separate issue.

[leonawicz]

Re: the different version of Python and GDAL, that makes sense. The issue I've had on Travis is not being able to install Python and/or GDAL via the config file in a way that makes the resources available to R on Travis. But I got some suggestions for that yesterday that may help there.

Sure, please just update the PR so that the change is just to remove the ignore.stderr = TRUE that's inside the internal system call and I'll merge it into master.

You can make the segfault issue another issue. I don't know what the cause is though. Maybe someone else will see the issue though and have some insight.

[jebyrnes]

Yup - already put in a PR - https://github.com/ropensci/tiler/pull/9 - but giving the user the option. Defaults to TRUE.

[leonawicz]

I mean let's just take the option back out entirely, but return the system call to its default of not having it ever suppress the stderr. Do you think there is any need to allow users to suppress it?

[jebyrnes]

OK, I see you merged. Issue fixed so that users can get reasonable feedback on what's happening when they call the python script! I'll comment on the closed issue when this awesome map becomes available!