Re: [GRASS-dev] Reviewing GSoC 2017 page

[massimo di stefano]

For web grass the ideal is to have a dedicated rendering system, based on GRASS 
data read by C++ in a buffer and rendered to html5 canvas or webgl directly. 
there is a gitter page if anyone is interested on web grass and want discuss 
its further development. 

For the jupyter notebook IMHO the easiest way to interact with grass, is to use 
a js framework as canvas and load images by converting grass data to jpeg or to 
 tiled images (ipyleaflet or cesiumpy are good options) I use gdal2tiles and 
gdaldem to generate ipyleaflet friendly images. 

The cons of this, as Rashad said, is that the grass data gets copied server 
side and will not be “in sync” in case the raster map is subject to some 
processing .. to keep the maps up-to-date I generate an sha-ash code for each 
raster and I connect it to a refresh button (ipywidgets) to regenerate the 
tiles or jpeg if the linked raster has changed.

The mapserver option introduce one more dependency … which can maybe annoying, 
but avoid to copy data by loading grass raster linked directly to the grass 
data  from a map file (needs goal-grass plugin)

I use the “js" method in a pyqt gui application loading leaflet and cesium in a 
qtwebengine, for personal use it works quite well .. but is hackish and 
suboptimal …

Massimo.


On Feb 3, 2017, at 2:14 PM, Margherita Di Leo  wrote:
> 
> 
> 
> On Thu, Jan 26, 2017 at 6:37 PM, Vaclav Petras  > wrote:
> 
> [...]
> 
> 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).
>  
> 
> See: https://github.com/SylvainCorlay/ipyleaflet 
> 
> 
> -- 
> Margherita Di Leo
> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-dev

___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Reviewing GSoC 2017 page

[Margherita Di Leo]

On Thu, Jan 26, 2017 at 6:37 PM, Vaclav Petras  wrote:

>
> [...]
>
> 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).
>


>
See: https://github.com/SylvainCorlay/ipyleaflet

-- 
Margherita Di Leo
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Reviewing GSoC 2017 page

[Rashad Kanavath]

On Thu, Jan 26, 2017 at 6:37 PM, Vaclav Petras  wrote:

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



-- 
Regards,
   Rashad
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Reviewing GSoC 2017 page

[Vaclav Petras]

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

Re: [GRASS-dev] Reviewing GSoC 2017 page

[Blumentrath, Stefan]

Thanks, quite some interesting GSoC ideas.

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

Regarding:
https://trac.osgeo.org/grass/wiki/GSoC/2017#AdditionalfunctionalityforrunningGRASSGISmodulesinJupyterNotebook
(which I also very much like to see become reality, esp. a function like 
“initGRASS()” from rgrass7) 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).

In order to be really useful, WebGRASS would need a console, and here Jupyter 
was already mentioned as an option. In addition the WebUI struggled quite a bit 
with renderinig… So will this proposal be complementary?

Cheers
Stefan

From: grass-dev [mailto:grass-dev-boun...@lists.osgeo.org] On Behalf Of Vaclav 
Petras
Sent: torsdag 26. januar 2017 00.22
To: grass-dev@lists.osgeo.org
Subject: Re: [GRASS-dev] Reviewing GSoC 2017 page

Worked. Thanks for tuning the spam filter, Markus. I just put all the new 
things at the beginning.

On Wed, Jan 25, 2017 at 10:01 AM, Vaclav Petras 
<wenzesl...@gmail.com<mailto:wenzesl...@gmail.com>> wrote:
Can somebody reorder the ideas so that the fresh ideas are at the top? When I 
try it, I get "Too many links" or "Page not modified".
Thanks,
Vaclav

___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Reviewing GSoC 2017 page

[Vaclav Petras]

Worked. Thanks for tuning the spam filter, Markus. I just put all the new
things at the beginning.

On Wed, Jan 25, 2017 at 10:01 AM, Vaclav Petras 
wrote:

> Can somebody reorder the ideas so that the fresh ideas are at the top?
> When I try it, I get "Too many links" or "Page not modified".
>
> Thanks,
> Vaclav
>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] Reviewing GSoC 2017 page

[Vaclav Petras]

Can somebody reorder the ideas so that the fresh ideas are at the top? When
I try it, I get "Too many links" or "Page not modified".

Thanks,
Vaclav
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev