Re: [GRASS-dev] [GRASS GIS] #3142: Implementing SLIC image segmentation

[GRASS GIS]

#3142: Implementing SLIC image segmentation
---+-
  Reporter:  SCrommelinck  |  Owner:  grass-dev@…
  Type:  enhancement   | Status:  closed
  Priority:  normal|  Milestone:  7.2.1
 Component:  Imagery   |Version:  unspecified
Resolution:  fixed |   Keywords:  SLIC image segmentation
   CPU:  Unspecified   |   Platform:  Unspecified
---+-
Changes (by mlennert):

 * status:  new => closed
 * resolution:   => fixed


Comment:

 i.superpixels.slic is now available as an addon, so closing.

--
Ticket URL: 
GRASS GIS 

___
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] "add to display" when running module from the SHELL

[Yann Chemin]

yes this is indeed a pickle.

maybe something like:
-> d.mon "get the selected wx display, if none, then d.mon wx0"

if exist and selected:
add output from this module to its "stack" (i.e. set of already run d.*
commands)
-> v.random in=bla.vect out=blaout.vect -a
the -a flag in the module would take the actual selected monitor history of
d.* commands and add one line with the "d.vect blaout.vect" at the end, and
run the new history in it.


?




--
Yann Chemin
Planetary Scientist
Latest: https://peerj.com/preprints/2124/
-
*JRC:*
https://www.thefreelibrary.com/3628+-+CANHEMON+Remote+sensing+based+forest+canopy+health+monitoring...-a0453990005
*OSGeo: *https://wiki.osgeo.org/wiki/Open_Monitoring_Systems_Working_Group


On 3 February 2017 at 11:10, Martin Landa  wrote:

> 2017-02-03 11:04 GMT+01:00 Yann Chemin :
> > say all raster and imagery and vector modules that generate output
> map(s), I
> > would like this(ese) map(s) to be added to the current stack in the
> current
> > display, the same way it works in the GUI version of the modules (i.e.
> > Check-box "Add created maps to layer tree").
>
> so, something like:
>
> # new flag -a: Add new maps to display automaticaly
> d.mon wx0 -a
> v.random out=p1 n=1000 # new map added to display
>
> ?
>
> But in this case you cannot control display parameters
> (d.vect/d.rast). There is no layer tree to define properties
> afterwards. I am not sure if such flag would make sense.
>
> Now you need:
>
> d.mon wx0
> v.random ...
> d.vect p1 ...
>
> Ma
>
> --
> Martin Landa
> http://geo.fsv.cvut.cz/gwiki/Landa
> http://gismentors.cz/mentors/landa
>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] GSoC proposal "Higher level API for C and C++" : need for discussion

[Sören Gebbert]

Hi,

[snip]
> IIUC, a higher-level C API would be between the current API and modules.
> What functionality is needed at this intermediate level ?
>
> Concerning the C++ API, I'm just a bit afraid that this will lead to more
> and more modules in C++ with the possible issues Markus mentions above.

Agreed.

>
> Also, what exactly is meant by:
>
> "Bridging of C++ RAII and try-catch with GRASS GIS C API exit and optional
> memory cleaning must be addressed."
>
> This sounds like another attempt to create persistent state in GRASS (I
> guess its this discussion [1] coming back ?). Again, I have no problem with
> discussing the issue once again, but I don't think this should be done
> within a GSoC project without prior discussion and consensus on the
> dev-list.

Agreed.

IMHO, there is no need for a higher level C or C++ API. Addressing the
memory and exit behavior of GRASS
can be managed in Python using an RPC interface to PyGRASS or
C-wrapper functionality [1].

It would be meaningful to improve the high level GRASS Python
interface that makes implementing
GRASS modules much easier than coding modules in C or C++.
Making the current GRASS RPC interface ground solid, providing more features,
so that it can be used in stable, long-running GUI applications may be
a better GSoC goal.

[1] https://grass.osgeo.org/grass73/manuals/libpython/_modules/pygrass/rpc.html

Just my 2cent
MfG
Sören
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] "add to display" when running module from the SHELL

[Martin Landa]

2017-02-03 11:04 GMT+01:00 Yann Chemin :
> say all raster and imagery and vector modules that generate output map(s), I
> would like this(ese) map(s) to be added to the current stack in the current
> display, the same way it works in the GUI version of the modules (i.e.
> Check-box "Add created maps to layer tree").

so, something like:

# new flag -a: Add new maps to display automaticaly
d.mon wx0 -a
v.random out=p1 n=1000 # new map added to display

?

But in this case you cannot control display parameters
(d.vect/d.rast). There is no layer tree to define properties
afterwards. I am not sure if such flag would make sense.

Now you need:

d.mon wx0
v.random ...
d.vect p1 ...

Ma

-- 
Martin Landa
http://geo.fsv.cvut.cz/gwiki/Landa
http://gismentors.cz/mentors/landa
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] "add to display" when running module from the SHELL

[Yann Chemin]

say all raster and imagery and vector modules that generate output map(s),
I would like this(ese) map(s) to be added to the current stack in the
current display, the same way it works in the GUI version of the modules
(i.e. Check-box "Add created maps to layer tree").


--
Yann Chemin
Planetary Scientist
Latest: https://peerj.com/preprints/2124/
-
*JRC:*
https://www.thefreelibrary.com/3628+-+CANHEMON+Remote+sensing+based+forest+canopy+health+monitoring...-a0453990005
*OSGeo: *https://wiki.osgeo.org/wiki/Open_Monitoring_Systems_Working_Group


On 3 February 2017 at 10:52, Martin Landa  wrote:

> 2017-02-03 10:40 GMT+01:00 Yann Chemin :
> > I meant a flag in the module.
>
> flag of the module? Which module? Ma
>
> --
> Martin Landa
> http://geo.fsv.cvut.cz/gwiki/Landa
> http://gismentors.cz/mentors/landa
>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] "add to display" when running module from the SHELL

[Martin Landa]

2017-02-03 10:40 GMT+01:00 Yann Chemin :
> I meant a flag in the module.

flag of the module? Which module? Ma

-- 
Martin Landa
http://geo.fsv.cvut.cz/gwiki/Landa
http://gismentors.cz/mentors/landa
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] "add to display" when running module from the SHELL

[Yann Chemin]

Thanks Martin,

I meant a flag in the module.

Yann

--
Yann Chemin
Planetary Scientist
Latest: https://peerj.com/preprints/2124/
-
*JRC:*
https://www.thefreelibrary.com/3628+-+CANHEMON+Remote+sensing+based+forest+canopy+health+monitoring...-a0453990005
*OSGeo: *https://wiki.osgeo.org/wiki/Open_Monitoring_Systems_Working_Group


On 3 February 2017 at 10:11, Martin Landa  wrote:

> Hi,
>
> 2017-02-03 9:44 GMT+01:00 Yann Chemin :
> > in the GUI of modules we can select to add to display,
> > is there (or would there be) a possibility to do the same when running
> from
> > the CLI/SHELL?
>
> d.mon wx0
> d.rast ...
> d.vect ...
> ...
>
> Ma
>
> --
> Martin Landa
> http://geo.fsv.cvut.cz/gwiki/Landa
> http://gismentors.cz/mentors/landa
>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] GSoC proposal "Implement cutline generation" - Looking for a mentor

[Taïs Grippa]

Dear dev team,

I would like to propose an idea for the 2017 GSoC (it is already on the 
GSoC 2017 GRASS wiki page).


It will be focused on 'meaningful' cutline generation.  I recently read 
a paper describing a method for cutline generation (see below [1] for 
the article, [2] for more references).


The procedure is composed of the following main steps:
1) Apply a High-pass filter - the "Prewitt South" filter 
(https://en.wikipedia.org/wiki/Prewitt_operator) to produce an edge image;

2) Apply a low-pass filter (mean for example) on the previous result;
3) Find the starting and finishing points (just based on pixel values in 
the first/last column/row);
4) Create an adjacency matrix on the result of 2) and use weights to 
give higher costs for specific directions (and force the cutline in to 
be quite linear between starting and finishing points);
5) Use the Dijkstra's algorithm 
(https://en.wikipedia.org/wiki/Dijkstra's_algorithm 
) to find the 
optimal cutline with a lowest cost between the starting and finishing point


Finding meaningful cutline in the image could be very interesting for 
tiling images in order to process segmentation in parallel. Instead of 
using arbitrary linear tiling, the segmented tiles could then be merged 
without post-processing of segments touching the tile's border.


If this algorithm would be implemented during the GSoC, it could be 
further adapted for huge enhancement of i.image.mosaic to enable 
mosaicking of overlapping scenes using cutline and become a real 
alternative to proprietary software 
(http://gis.stackexchange.com/questions/127310/how-to-create-a-mosaic-in-qgis-with-cutline-and-feathering-for-landsat-8-imagery). 



As the proposed solution [1] for cutline is working on a single image, 
It should be adapted to take into account pixel values of two images so.
I can give a support for the content of the project, but I don't have 
the necessary programming skills for supervision of GSoC student. So, I 
would like to know if someone would be interested by being the mentor 
for this project !

Concerning the language requirements for this project I guess it will be C ?

[1] Soares, Anderson Reis, Thales Sehn Körting, et Leila Maria Garcia 
Fonseca. 2016. « Improvements of the divide and segment method for 
parallel image segmentation ». Brazilian Journal of Cartography 68 (6). 
https://www.researchgate.net/publication/286929006_Improvements_of_the_divide_and_segment_method_for_parallel_image_segmentation


[2] Körting, Thales Sehn, Emiliano Ferreira Castejon, et Leila Maria 
Garcia Fonseca. 2013. « The Divide and Segment Method for Parallel Image 
Segmentation ». In Advanced Concepts for Intelligent Vision Systems, 504 
15. Springer, Cham. doi:10.1007/978-3-319-02895-8_45. 
https://www.researchgate.net/publication/265794792_The_Divide_and_Segment_Method_for_Parallel_Image_Segmentation


Best,
--

*M. GRIPPA Taïs*
Geographer - Phd student IGEAT - ANAGEO
ULB CP 130/03 Av. F.D. Roosevelt, 50 - 1050 Bruxelles
Tél: 02/650.68.06
Mail: tais.gri...@ulb.ac.be
Web: http://maupp.ulb.ac.be/
 



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

Re: [GRASS-dev] GSoC proposal "Higher level API for C and C++" : need for discussion

[Moritz Lennert]

On 02/02/17 09:22, Markus Metz wrote:



On Wed, Feb 1, 2017 at 10:46 PM, Vaclav Petras mailto:wenzesl...@gmail.com>> wrote:



On Wed, Feb 1, 2017 at 3:24 PM, Moritz Lennert

mailto:mlenn...@club.worldonline.be>> wrote:


I don't really agree with the idea that

"Unfortunately, its [GRASS'] development is stagnating because of

small interest

from fresh and young developers. This is partially caused by the fact

that its design and

concepts are overcome by modern practices in a software development."

I do not see GRASS stagnating. And even though GRASS uses an "old"

language,



I think C is fine and that might be more clear now than in 2008, but

C++ is popular too.

C++ is more problematic in terms of portability and robustness over
time, have a look at the revision log of e.g. r.terraflow and the
iostream library.


However, the motivation for GSoC is make writing of modules in C and

C++ easier. We may discuss if "development is stagnating because of
small interest" is true or not, but for sure we can have better
interface which would attract more people.

Then the project should determine what is "better". This could be a
project where a concept is going to be developed without writing a
single line of code. The main objective would then be to first identify
what is bad or too complicated and how to improve on it.


More pressing problem however are the modules which use variants of

all-in-memory and tiling-on-disk raster reading modes. I'm not sure what
is the state now, because MarkusM fixed a lot of those, but some addons
were not included into core because of custom segment libraries (and
even now they have custom all-in-memory implementations).

There are only a few modules requiring random access and external memory
(e.g. but not only tiling on disk). IMHO, random access and usage of
external memory are special cases, and I don't see how a higher-level
API would help with these special cases.

All-in-memory processing is so simple that any API would IMHO make
things more complicated.

The interface to the segment library is pretty simple: you need only
Segment_open(), Segment_put(), Segment_get(), Segment_close().

Maybe it would help if there would a better description about the
differences in the tiling-on-disk methods available in GRASS, i.e. the
segment library, the read-only cache used by r.proj, and the rowio library.




I imagine that it's unpleasant if all you believe in is OO, but that

doesn't necessarily make OO the naturally best way to go... :-)



Similarly to Python API, OOP is not the only thing we should focus on.

C++ is a multiparadigm language and OOP is just part of it (e.g.
templates are kind of big), plus there are different levels of doing OOP
("C with classes" versus more complicated OOP). So yes, the student
should be familiar with more than just OOP.

Note that the vast majority of portability and compatibility issues
arises from Python and C++.

Maybe this proposal addresses two different things that could be kept
separated:
1) some higher-level C and C++ API


IIUC, a higher-level C API would be between the current API and modules. 
What functionality is needed at this intermediate level ?


Concerning the C++ API, I'm just a bit afraid that this will lead to 
more and more modules in C++ with the possible issues Markus mentions above.


Also, what exactly is meant by:

"Bridging of C++ RAII and try-catch with GRASS GIS C API exit and 
optional memory cleaning must be addressed."


This sounds like another attempt to create persistent state in GRASS (I 
guess its this discussion [1] coming back ?). Again, I have no problem 
with discussing the issue once again, but I don't think this should be 
done within a GSoC project without prior discussion and consensus on the 
dev-list.


Moritz


[1] https://lists.osgeo.org/pipermail/grass-dev/2014-April/068345.html
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] "add to display" when running module from the SHELL

[Martin Landa]

Hi,

2017-02-03 9:44 GMT+01:00 Yann Chemin :
> in the GUI of modules we can select to add to display,
> is there (or would there be) a possibility to do the same when running from
> the CLI/SHELL?

d.mon wx0
d.rast ...
d.vect ...
...

Ma

-- 
Martin Landa
http://geo.fsv.cvut.cz/gwiki/Landa
http://gismentors.cz/mentors/landa
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] "add to display" when running module from the SHELL

[Yann Chemin]

Hi,

in the GUI of modules we can select to add to display,
is there (or would there be) a possibility to do the same when running from
the CLI/SHELL?

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