[GRASS-dev] Reviewing GSoC 2017 page

Rashad Kanavath mohammedrashadkm at gmail.com
Fri Feb 3 05:01:54 PST 2017


On Thu, Jan 26, 2017 at 6:37 PM, Vaclav Petras <wenzeslaus at gmail.com> wrote:

>
> 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#Additionalfuncti
>> onalityforrunningGRASSGISmodulesinJupyterNotebook
>>
>> (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/w
>> iki/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.
>>
>
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.
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.



> 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?
>>
>
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.



> 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 at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-dev
>



-- 
Regards,
   Rashad
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/grass-dev/attachments/20170203/487cc5d6/attachment.html>


More information about the grass-dev mailing list