[GRASS-dev] Reviewing GSoC 2017 page

Vaclav Petras wenzeslaus at gmail.com
Thu Jan 26 09:37:48 PST 2017


On Wed, Jan 25, 2017 at 6:35 PM, Blumentrath, Stefan <
Stefan.Blumentrath at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/grass-dev/attachments/20170126/ccd4ed42/attachment.html>


More information about the grass-dev mailing list