On Wed, Jan 25, 2017 at 6:35 PM, Blumentrath, Stefan < stefan.blumentr...@nina.no> wrote:
> I took the liberty to add one on “tools for generating unit tests from > examples in module manuals”. Not sure if that is feasible or out of scope. > Please feel free to remove it if you don`t find it suitable (I can`t mentor > it anyway). > It is valid, but there is a lot of details which need to be considered (would need to be addressed in the proposal). There is some post to mailing list discussing some of those. > > > Regarding: > > https://trac.osgeo.org/grass/wiki/GSoC/2017#Additionalfunctionalityforrunn > ingGRASSGISmodulesinJupyterNotebook > > (which I also very much like to see become reality, esp. a function like > “initGRASS()” from rgrass7) > Can you please be specific about differences between rgrass7 initGRASS() and grass.script.setup.init()? It would be good to collect them. https://grass.osgeo.org/grass70/manuals/libpython/script.html#module-script.setup Here is an example from action where it is simplified (and not that robust) but adds some other useful things: https://github.com/wenzeslaus/geospatial-modeling-course-jupyter/blob/master/notebooks/buffers_cost.ipynb Other thing to mention is that an ultimate solution may involve creating a package separate from GRASS GIS (like rgrass7) and more importantly changing the way GRASS GIS is installed and distributed (see e.g. ticket for PyGRASS outside of GRASS session). > I have the question if that by chance is supposed to be related to last > years GSoC on a WebGUI for GRASS (see: https://trac.osgeo.org/grass/ > wiki/GSoC/2016/WebGrass). > Not directly related. Jupyter Notebook is independent and with some additions of interactive maps it could be used as a web interface for advanced or Python aware users. It can be used even now, but for visualization, you need to deal with d.* commands (which is fine in general but not for zooming, panning, ...) or you need to plug in other solution for visualization (like MapServer reading from GRASS GIS Database). There might be some code sharing between (some/any) web GRASS and Jupyter on the side of Python API or JavaScript map display (if applicable). > > > In order to be really useful, WebGRASS would need a console, and here > Jupyter was already mentioned as an option. > For this part it is really just thing of WebGRASS, nothing to be done on Jupyter site. > In addition the WebUI struggled quite a bit with renderinig… So will this > proposal be complementary? > I don't know what specifically you mean, but I guess it will be a struggle for Jupyer as well.
_______________________________________________ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev
