<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jan 26, 2017 at 6:37 PM, Vaclav Petras <span dir="ltr"><<a href="mailto:wenzeslaus@gmail.com" target="_blank">wenzeslaus@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote"><span class="">On Wed, Jan 25, 2017 at 6:35 PM, Blumentrath, Stefan <span dir="ltr"><<a href="mailto:Stefan.Blumentrath@nina.no" target="_blank">Stefan.Blumentrath@nina.no</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><p class="MsoNormal"><span style="font-size:11pt;font-family:"calibri",sans-serif;color:rgb(31,73,125)" lang="EN-US">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).</span></p></blockquote><div><br></div></span><div>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.<br></div><span class=""><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><p class="MsoNormal"><span style="font-size:11pt;font-family:"calibri",sans-serif;color:rgb(31,73,125)" lang="EN-US"><u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:"calibri",sans-serif;color:rgb(31,73,125)" lang="EN-US"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:"calibri",sans-serif;color:rgb(31,73,125)" lang="EN-US">Regarding:<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:"calibri",sans-serif;color:rgb(31,73,125)" lang="EN-US"><a href="https://trac.osgeo.org/grass/wiki/GSoC/2017#AdditionalfunctionalityforrunningGRASSGISmodulesinJupyterNotebook" target="_blank">https://trac.osgeo.org/grass/w<wbr>iki/GSoC/2017#Additionalfuncti<wbr>onalityforrunningGRASSGISmodul<wbr>esinJupyterNotebook</a><u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:"calibri",sans-serif;color:rgb(31,73,125)" lang="EN-US">(which I also very much like to see become reality, esp. a function like “initGRASS()” from rgrass7) </span></p></blockquote><div><br></div></span><div>Can you please be specific about differences between rgrass7 initGRASS() and grass.script.setup.init()? It would be good to collect them.<br><br><a href="https://grass.osgeo.org/grass70/manuals/libpython/script.html#module-script.setup" target="_blank">https://grass.osgeo.org/<wbr>grass70/manuals/libpython/<wbr>script.html#module-script.<wbr>setup</a><br><br></div><div>Here is an example from action where it is simplified (and not that robust) but adds some other useful things:<br><br><a href="https://github.com/wenzeslaus/geospatial-modeling-course-jupyter/blob/master/notebooks/buffers_cost.ipynb" target="_blank">https://github.com/wenzeslaus/<wbr>geospatial-modeling-course-<wbr>jupyter/blob/master/notebooks/<wbr>buffers_cost.ipynb</a><br><br></div><div>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).<br></div><span class=""><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><p class="MsoNormal"><span style="font-size:11pt;font-family:"calibri",sans-serif;color:rgb(31,73,125)" lang="EN-US">I have the question
if that by chance is supposed to be related to last years GSoC on a WebGUI for GRASS (see: <a href="https://trac.osgeo.org/grass/wiki/GSoC/2016/WebGrass" target="_blank">https://trac.osgeo.org/grass/w<wbr>iki/GSoC/2016/WebGrass</a>).</span></p></blockquote><div><br></div></span><div>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).<br></div><span class=""><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><p class="MsoNormal"><span style="font-size:11pt;font-family:"calibri",sans-serif;color:rgb(31,73,125)" lang="EN-US"><u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:"calibri",sans-serif;color:rgb(31,73,125)" lang="EN-US"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:"calibri",sans-serif;color:rgb(31,73,125)" lang="EN-US">In order to be really useful, WebGRASS would need a console, and here Jupyter was already mentioned as an option.</span></p></blockquote></span></div></div></div></blockquote><div><br></div><div>Adding a console is good idea on webgrass. If someone wants to in help (coding), I would be happy to mentor (out of GSoC) in evolving webgrass.<br></div><div>AFAICT, the core thing is how do we communicate to grass from client browser. IPython is one option. webgrass tries to mimic (most parts of) desktop ui. And instead of dealing with d.* commands, we interact directly with grass data and put them on HTML5. IPython and others does not play well when dealing interacting with maps. writing to file and then reading cost us lot of I/O which btw are critical in many cases.<br><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class=""><div><br></div></span><div>For this part it is really just thing of WebGRASS, nothing to be done on Jupyter site.<br></div><span class=""><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><p class="MsoNormal"><span style="font-size:11pt;font-family:"calibri",sans-serif;color:rgb(31,73,125)" lang="EN-US"> In addition
the WebUI struggled quite a bit with renderinig… So will this proposal be complementary?</span></p></blockquote></span></div></div></div></blockquote><div><br></div><div>rendering of maps? we don't have a better replacement on this part right now. Some thing that is clean code and good will be costly in terms of development effort. <br><br><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><br></div><div class="gmail_extra">I don't know what specifically you mean, but I guess it will be a struggle for Jupyer as well.<br></div></div>
<br>______________________________<wbr>_________________<br>
grass-dev mailing list<br>
<a href="mailto:grass-dev@lists.osgeo.org">grass-dev@lists.osgeo.org</a><br>
<a href="https://lists.osgeo.org/mailman/listinfo/grass-dev" rel="noreferrer" target="_blank">https://lists.osgeo.org/<wbr>mailman/listinfo/grass-dev</a><br></blockquote></div><br><br clear="all"><br>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div><font face="arial, helvetica, sans-serif">Regards,<br> Rashad</font></div></div>
</div></div>