Add temporary files for Non-Interactive Display

[chaedri]

• Write display-related files to temporary files for non-interactive displays in Jupyter Notebooks. The option remains to write the display to a PNG when provided a path and filename.
• Edit grass.jupyter demonstration notebook to include example with legend.
• Improved Documentation and added renderer parameter to GrassRenderer

These modifications are part of an on-going Google Summer of Code project, Improved Integration of GRASS GIS and Jupyter Notebooks. You can find more information here.

You can also try out the changes suggested in this PR here:

https://mybinder.org/v2/gh/chaedri/grass/add-temp-directory?urlpath=lab%2Ftree%2Fdoc%2Fnotebooks%2Fjupyter_integration.ipynb

[veroandreo]

There's an error when creating the second instance of GrassRenderer

~/dist.x86_64-pc-linux-gnu/etc/python/grass/jupyter/display.py in __init__(self, env, width, height, filename, text_size)
     37             tmpfile = tempfile.NamedTemporaryFile(suffix=".png")
     38             self._env["GRASS_RENDER_FILE"] = tmpfile.name
---> 39         self._filename = tmpfile.name
     40         # Environment Settings
     41         self._env["GRASS_RENDER_WIDTH"] = str(width)

UnboundLocalError: local variable 'tmpfile' referenced before assignment

if the filename part is removed, then it displays the second map

[chaedri]

There's an error when creating the second instance of GrassRenderer

~/dist.x86_64-pc-linux-gnu/etc/python/grass/jupyter/display.py in __init__(self, env, width, height, filename, text_size)
     37             tmpfile = tempfile.NamedTemporaryFile(suffix=".png")
     38             self._env["GRASS_RENDER_FILE"] = tmpfile.name
---> 39         self._filename = tmpfile.name
     40         # Environment Settings
     41         self._env["GRASS_RENDER_WIDTH"] = str(width)

UnboundLocalError: local variable 'tmpfile' referenced before assignment

if the filename part is removed, then it displays the second map

I think you must've clicked on the link a few minutes ago - that error shouldn't occur anymore. I fixed it in commit 3ac09fc - sorry about that!

[veroandreo]

There's an error when creating the second instance of GrassRenderer

~/dist.x86_64-pc-linux-gnu/etc/python/grass/jupyter/display.py in __init__(self, env, width, height, filename, text_size)
     37             tmpfile = tempfile.NamedTemporaryFile(suffix=".png")
     38             self._env["GRASS_RENDER_FILE"] = tmpfile.name
---> 39         self._filename = tmpfile.name
     40         # Environment Settings
     41         self._env["GRASS_RENDER_WIDTH"] = str(width)

UnboundLocalError: local variable 'tmpfile' referenced before assignment

if the filename part is removed, then it displays the second map

I think you must've clicked on the link a few minutes ago - that error shouldn't occur anymore. I fixed it in commit 3ac09fc - sorry about that!

Yes, all good now! :)

[chaedri]

I switched to TemporaryDirectory after realizing that the temporary files weren't cleaning up correctly. tempfile removes temporary files after they are closed but each time a d.* GRASS module modifies the file, it opens and closes the file (thereby deleting it). Using a temporary directory avoids this because the directory is cleaned-up after "exiting the current context" which, in this case, I think means after the python kernal is restarted or shut down.

[wenzeslaus]

@chaedri Just to clarify:

I switched to TemporaryDirectory after realizing that the temporary files weren't cleaning up correctly.

What have you actually observed? I would expect files to be left behind. I would expect them to be deleted by the named temporary file object, but then re-created by the d-commands.

'tempfile' removes temporary files after they are closed but each time a 'd.*' GRASS module modifies the file, it opens and closes the file (thereby deleting it).

The closing in the documentation refers to closing the "file descriptor" linked to the named temporary file object. The subprocess opening and closing is unrelated. However, the documentation also suggests that opening the file multiple times or from other processes may not work well or may not work on all platforms.

Using a temporary directory avoids this because the directory is cleaned-up after "exiting the current context" which, in this case, I think means after the python kernal is restarted or shut down.

When I saw your changed, I remembered we already talked about it and I think it is the way to go. I just want to make sure you didn't observed anything which would be contrary to what we understood from the documentation previously.

[chaedri]

@chaedri Just to clarify:

I switched to TemporaryDirectory after realizing that the temporary files weren't cleaning up correctly.

What have you actually observed? I would expect files to be left behind. I would expect them to be deleted by the named temporary file object, but then re-created by the d-commands.

I think that is correct based on my experiments. I found the /tmp directory on my computer and could see that the files weren't being deleted, even after the kernal was shut down. Then, I tried adding the temporary file object as an attribute (self._tmpfile) so that it wouldn't close/delete. In this case, the map didn't render as expected: it only displays the last layer added to the file (for example, running d.rast for elevation then d.vect for streams will display a map of only streams but if you just run d.rast for elevation, you will get a map of elevation).

'tempfile' removes temporary files after they are closed but each time a 'd.*' GRASS module modifies the file, it opens and closes the file (thereby deleting it).

The closing in the documentation refers to closing the "file descriptor" linked to the named temporary file object. The subprocess opening and closing is unrelated. However, the documentation also suggests that opening the file multiple times or from other processes may not work well or may not work on all platforms.

Using a temporary directory avoids this because the directory is cleaned-up after "exiting the current context" which, in this case, I think means after the python kernal is restarted or shut down.

When I saw your changed, I remembered we already talked about it and I think it is the way to go. I just want to make sure you didn't observed anything which would be contrary to what we understood from the documentation previously.

I don't think I did.