Re: [GRASS-dev] FW: FW: OSGeo-SoC 2016 application

2016-03-25 Thread Moritz Lennert 

Bo,

I've read through your application. It is quite long, so I think you can 
shorten the overview of the different algorithms a bit.


Maybe I was, again, unclear in my previous mails, but I would qualify 
mean-shift and watershed as top-down algorithms. If your not comfortable 
with these notions (of top-down/bottom-up), better not to include them 
in the proposal.


Other than that, it seems fine to me.

Some elements you could add to make it stronger:

- The specific question of how to handle large data. i.segment uses 
binary search trees. Have you already worked with those ? As you say 
that you "coded to process large volume" data, could you provide one or 
two examples including information about your approaches ?
- Possible difficulties and how you plan on solving them (including 
other obligations you might have during that time, vacation plans, etc).
- Have you ever worked in a *nix environment ? Even though GRASS runs on 
Windows, it does come from a *nix environment and understanding that 
helps...


I won't be available for most of (my) afternoon. I'll try to have a 
quick look at my mail around 18h (CET), i.e. 2 hours before deadline, 
but can't absolutely guarantee it.


Maybe MarkusM has something to add ?

Moritz


On 25/03/16 06:21, Yang, Bo (yangb2) wrote:

Dear Moritz,

Please find the attachment for my first draft of the proposal.
GoogleDoc:
https://docs.google.com/document/d/1Qanh7sUdJZfiusTVIBHmlbC6NY9kKFVR18OL3icreoM/edit?usp=sharing

Thanks for your advices, such as Orfeo Toolbox, those are really helpful
for further understanding the segmentation algorithms.

However, I find few literature about the split-window algorithm, So for
the time being I put mean-shift and watershed as my highest priority
algorithm to be implemented.

Please let me know if you and/or Markus have any suggestions. I didn't
strictly follow the proposal template[1] because there is no methods
part. I restructure the proposal and included all the required
information in the template. If needed I can revise it to exactly follow
template's format. The proposal is due tomorrow afternoon for me (3pm
EST) so I think I still have enough time to refine it.

Yes, I fully understand there is no guarantee that the proposal will be
accepted, and I am totally fine with it. Thanks for pointing it out. Be
engaging in the GSoC process is more valuable for me since I've learning
about groups of people that extend beyond just GSoC. I will try my best.

Best regards,

Bo Yang

[1]
https://wiki.osgeo.org/wiki/Google_Summer_of_Code_Recommendations_for_Students#Application_questions_we.27ll_ask_you

-Original Message-
From: Moritz Lennert [mailto:mlenn...@club.worldonline.be]
Sent: Thursday, March 24, 2016 7:52 AM
To: Yang, Bo (yangb2) <yan...@mail.uc.edu>; Luca Delucchi
<lucadel...@gmail.com>
Cc: grass-dev@lists.osgeo.org; Markus Metz <markus.metz.gisw...@gmail.com>
Subject: Re: [GRASS-dev] FW: FW: OSGeo-SoC 2016 application

Dear Bo,

On 24/03/16 06:26, Yang, Bo (yangb2) wrote:

 > Dear Moritz,

 >

 > Thank you for the reply, and thanks you and Markus could be the mentor

 > of the i.segment project! There are only two days left for submitting

 > the proposal, take into consideration I think I need to switch to the

 > topic of i.segment project now.

Thank you for the flexibility !

 > For my cokriging fusion

 > topic I think I could do it after this summer in the future work.

Great !

 > I've read the source code and Eric's wiki of GSoC 2012 [0]. I think I

 > will prepare the proposal following the direction of adding new

 > algorithms to segment an image into objects-- more than region-growing

 > algorithm. Moritz, you mentioned segmentation

 > algorithm: mean-shift, split-window and watershed.

Yes, as the general logistics of the i.segment module is in place,
adding new segmentation algorithms should not be too hard, so adding
several should be possible during this GSoC.

 > I think some

 > unsupervised classification algorithms would also be possible such

 > as: dynamic thresholding and markov random field (MRF).

Unsupervised classification could be an interesting addition.

However, I would think KISS. So, concentrate on the segmentation. You
can add classification in the the project as a possible extension, in
case you finish early with the segmentation.

In any case, classification should be a separate module. The idea is to
have each module do one thing. Currently classification is proposed by
v.class.ml and v.class.mlR (but the latter is a very simple hack I did
for teaching - I'm currently busy rewriting it), but they are supervised.

For classification segment characterization is also important. Currently
we have two Python-based modules for that v.class and i.segment.stats.

One option might be to think about more efficient approaches and more
variables for that.

 > If you think

 > it is OK, I will start the p

Re: [GRASS-dev] FW: FW: OSGeo-SoC 2016 application

2016-03-24 Thread Moritz Lennert 

Dear Bo,

On 24/03/16 06:26, Yang, Bo (yangb2) wrote:

Dear Moritz,

Thank you for the reply, and thanks you and Markus could be the
mentor of the i.segment project! There are only two days left for
submitting the proposal, take into consideration I think I need to
switch to the topic of i.segment project now.


Thank you for the flexibility !


For my cokriging fusion
topic I think I could do it after this summer in the future work.


Great !


I've read the source code and Eric's wiki of GSoC 2012 [0]. I think I
will prepare the proposal following the direction of adding new
algorithms to segment an image into objects-- more than
region-growing algorithm. Moritz, you mentioned segmentation
algorithm: mean-shift, split-window and watershed.


Yes, as the general logistics of the i.segment module is in place, 
adding new segmentation algorithms should not be too hard, so adding 
several should be possible during this GSoC.



I think some
unsupervised classification algorithms would also be possible such
as: dynamic thresholding and markov random field (MRF).


Unsupervised classification could be an interesting addition.

However, I would think KISS. So, concentrate on the segmentation. You 
can add classification in the the project as a possible extension, in 
case you finish early with the segmentation.


In any case, classification should be a separate module. The idea is to 
have each module do one thing. Currently classification is proposed by 
v.class.ml and v.class.mlR (but the latter is a very simple hack I did 
for teaching - I'm currently busy rewriting it), but they are supervised.


For classification segment characterization is also important. Currently 
we have two Python-based modules for that v.class and i.segment.stats. 
One option might be to think about more efficient approaches and more 
variables for that.




If you think
it is OK, I will start the preparing the draft of proposal from now
on, and I think I could have the first version send back to you by
tomorrow (Thursday).


Perfect. Markus and I are in Europe so don't forget about time zones 
when thinking about when to send us your draft...



If you have any suggestions and comments please
let me know.


Markus can give you more details about the actual implementation. I 
think in your proposal you should show that you have a general idea of 
how i.segment works, and you should review different segmentation 
techniques, possibly with relevant literature references. You might also 
want to have a look at Orfeo Toolbox and their implementation of some of 
the segmentation algorithms.


In general, it would be nice to add at least one or two top-down methods 
as this would allow top-down hierarchical segmentation, while the 
current region growing approach only allows bottom-up hierarchical 
segmentation.


Final note just to make sure that this is clear: please be aware that 
there are other GRASS-related proposals and that we do not know how many 
slots we will get for GRASS. There is thus no guarantee that your 
proposal will be chosen.


Best wishes,
Moritz
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] FW: FW: OSGeo-SoC 2016 application

2016-03-23 Thread Yang, Bo (yangb2) 
Dear Moritz,

Thank you for the reply, and thanks you and Markus could be the mentor of the 
i.segment project! There are only two days left for submitting the proposal, 
take into consideration I think I need to switch to the topic of i.segment 
project now. For my cokriging fusion topic I think I could do it after this 
summer in the future work. 
I've read the source code and Eric's wiki of GSoC 2012 [0]. I think I will 
prepare the proposal following the direction of adding new algorithms to 
segment an image into objects-- more than region-growing algorithm. Moritz, you 
mentioned segmentation algorithm: mean-shift, split-window and watershed. I 
think some unsupervised classification algorithms would also be possible such 
as: dynamic thresholding and markov random field (MRF). If you think it is OK, 
I will start the preparing the draft of proposal from now on, and I think I 
could have the first version send back to you by tomorrow (Thursday). If you 
have any suggestions and comments please let me know.
Thanks again to both you and Luca for your guidance and patient. 

Best wishes,
Bo Yang

[0] https://grasswiki.osgeo.org/wiki/GRASS_GSoC_2012_Image_Segmentation


-Original Message-
From: Moritz Lennert [mailto:mlenn...@club.worldonline.be] 
Sent: Wednesday, March 23, 2016 10:12 AM
To: Yang, Bo (yangb2) <yan...@mail.uc.edu>
Cc: Luca Delucchi <lucadel...@gmail.com>; grass-dev@lists.osgeo.org; Markus 
Metz <markus.metz.gisw...@gmail.com>
Subject: Re: [GRASS-dev] FW: FW: OSGeo-SoC 2016 application

Le Wed, 23 Mar 2016 09:09:06 +0100,
Luca Delucchi <lucadel...@gmail.com> a écrit :

> On 23 March 2016 at 05:04, Yang, Bo (yangb2) <yan...@mail.uc.edu>
> wrote:
> > Dear Luca,
> >  
> 
> Dear Bo,
> 
> > Last weekend I've tried using my computer checking out the source 
> > codes and compiled the GRASS in the windows OS environment [0]. In 
> > addition, I've studied both t.rast.gapfill and r.series.interp 
> > modules. I think that it would be possible to add an interpolation 
> > method because it currently supports only linear interpolation. I 
> > think it would be a good idea to add Kriging/cokriging to the 
> > interpolation methods since it is a wide used rater interpolation 
> > algorithm. Although Kriging/cokriging computational time is 
> > significantly longer than the traditional linear method, it 
> > completes the gap filling process within a reasonable period with 
> > much better fusion results, especially for some heterogeneous 
> > region. If you think it is OK, I can prepare the proposal follow 
> > this direction (it is due this Friday).
> 
> I think you should start the proposal, because there is no so much 
> time
> 
> > However, I've got the reply from Soeren (see below). He said he 
> > can't mentor the project due to too busy this year. Do you have any 
> > other person in mind to recommend as mentor? Or are you available 
> > for  mentoring this project? Please advise. Thank you for being 
> > patient and helping me.
> 
> I have no enough C skills to be the first mentor, I could be the 
> co-mentor (for testing, helping you with t.rast.gapfill and adding 
> tests). Is someone else interested to be mentor?

As mentioned privately, I'm only available, like you, as co-mentor for testing 
and applied advice, not so much on the coding side.

In light of the absence of mentors, you might want to reconsider the choice of 
topics. For i.segment, Markus Metz is willing to deal with the C-side and I 
mentor for the rest.

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

Re: [GRASS-dev] FW: FW: OSGeo-SoC 2016 application

2016-03-23 Thread Moritz Lennert 
Le Wed, 23 Mar 2016 09:09:06 +0100,
Luca Delucchi  a écrit :

> On 23 March 2016 at 05:04, Yang, Bo (yangb2) 
> wrote:
> > Dear Luca,
> >  
> 
> Dear Bo,
> 
> > Last weekend I've tried using my computer checking out the source
> > codes and compiled the GRASS in the windows OS environment [0]. In
> > addition, I've studied both t.rast.gapfill and r.series.interp
> > modules. I think that it would be possible to add an interpolation
> > method because it currently supports only linear interpolation. I
> > think it would be a good idea to add Kriging/cokriging to the
> > interpolation methods since it is a wide used rater interpolation
> > algorithm. Although Kriging/cokriging computational time is
> > significantly longer than the traditional linear method, it
> > completes the gap filling process within a reasonable period with
> > much better fusion results, especially for some heterogeneous
> > region. If you think it is OK, I can prepare the proposal follow
> > this direction (it is due this Friday). 
> 
> I think you should start the proposal, because there is no so much
> time
> 
> > However, I've got the reply from Soeren (see below). He said he
> > can't mentor the project due to too busy this year. Do you have any
> > other person in mind to recommend as mentor? Or are you available
> > for  mentoring this project? Please advise. Thank you for being
> > patient and helping me. 
> 
> I have no enough C skills to be the first mentor, I could be the
> co-mentor (for testing, helping you with t.rast.gapfill and adding
> tests). Is someone else interested to be mentor?

As mentioned privately, I'm only available, like you, as co-mentor for
testing and applied advice, not so much on the coding side.

In light of the absence of mentors, you might want to reconsider the
choice of topics. For i.segment, Markus Metz is willing to deal with
the C-side and I mentor for the rest.

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

Re: [GRASS-dev] FW: FW: OSGeo-SoC 2016 application

2016-03-23 Thread Luca Delucchi 
On 23 March 2016 at 05:04, Yang, Bo (yangb2)  wrote:
> Dear Luca,
>

Dear Bo,

> Last weekend I've tried using my computer checking out the source codes and 
> compiled the GRASS in the windows OS environment [0]. In addition, I've 
> studied both t.rast.gapfill and r.series.interp modules. I think that it 
> would be possible to add an interpolation method because it currently 
> supports only linear interpolation. I think it would be a good idea to add 
> Kriging/cokriging to the interpolation methods since it is a wide used rater 
> interpolation algorithm. Although Kriging/cokriging computational time is 
> significantly longer than the traditional linear method, it completes the gap 
> filling process within a reasonable period with much better fusion results, 
> especially for some heterogeneous region. If you think it is OK, I can 
> prepare the proposal follow this direction (it is due this Friday).
>

I think you should start the proposal, because there is no so much time

> However, I've got the reply from Soeren (see below). He said he can't mentor 
> the project due to too busy this year. Do you have any other person in mind 
> to recommend as mentor? Or are you available for  mentoring this project? 
> Please advise.
> Thank you for being patient and helping me.
>

I have no enough C skills to be the first mentor, I could be the
co-mentor (for testing, helping you with t.rast.gapfill and adding
tests). Is someone else interested to be mentor?

> Best wishes,
> Bo Yang
>


-- 
ciao
Luca

http://gis.cri.fmach.it/delucchi/
www.lucadelu.org
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] FW: FW: OSGeo-SoC 2016 application

2016-03-22 Thread Yang, Bo (yangb2) 
Dear Luca,

Last weekend I've tried using my computer checking out the source codes and 
compiled the GRASS in the windows OS environment [0]. In addition, I've studied 
both t.rast.gapfill and r.series.interp modules. I think that it would be 
possible to add an interpolation method because it currently supports only 
linear interpolation. I think it would be a good idea to add Kriging/cokriging 
to the interpolation methods since it is a wide used rater interpolation 
algorithm. Although Kriging/cokriging computational time is significantly 
longer than the traditional linear method, it completes the gap filling process 
within a reasonable period with much better fusion results, especially for some 
heterogeneous region. If you think it is OK, I can prepare the proposal follow 
this direction (it is due this Friday). 

However, I've got the reply from Soeren (see below). He said he can't mentor 
the project due to too busy this year. Do you have any other person in mind to 
recommend as mentor? Or are you available for  mentoring this project? Please 
advise. 
Thank you for being patient and helping me.

Best wishes,
Bo Yang

[0] https://trac.osgeo.org/grass/wiki/CompileOnWindows


-Original Message-
From: Sören Gebbert [mailto:soeren.gebb...@thuenen.de] 
Sent: Monday, March 21, 2016 10:36 AM
To: Yang, Bo (yangb2) 
Subject: Re: FW: [GRASS-dev] OSGeo-SoC 2016 application

Dear Bo,
sorry for my late response.

Your project sounds very interesting indeed. However, i am really sorry to tell 
you that i have no time this year to mentor a GSoC2016 project. I have to work 
on so many different projects right now, that i am not able to spend time on 
GSoC2016.

Best regards
Soeren

> Dear Soeren,
>
> I hope this email finds you well.
> I apologize for the multiple emails, I am forwarding this email in 
> case you didn't see the earlier one I sent to "soerengebb...@googlemail.com ".
> Thank you and have a good day.
>
> Best regards,
> Bo yang
>
>
> -Original Message-
> From: Yang, Bo (yangb2)
> Sent: Thursday, March 17, 2016 12:39 AM
> To: 'Luca Delucchi' ; Sören Gebbert 
> 
> Cc: grass-dev@lists.osgeo.org
> Subject: RE: [GRASS-dev] OSGeo-SoC 2016 application
>
> Dear Soeren and Luca,
>
> First, let me introduce myself again to Soeren. My name is Bo Yang, a Ph.
> D. student in the Department of Geography, University of Cincinnati, 
> OH, USA.  I have a bachelor degree in Mathematics and MS in Computer Science.
> I am really interested in OSGeo-SoC2016. It would be a great 
> opportunity if I can make contributions as well as learn to become an 
> open-source developer.
>
> Currently I have an idea based on my MA thesis project: 
> Spatio-temporal fusion of multi-scale data with in a cokriging framework.
> This project extends traditional cokriging method for blending spatial 
> data sets with different temporal sampling frequency and spatial 
> resolution (density). It can be used for both raster data and vector 
> data, effectively fill in data gaps due to severe weather condition, 
> instrument malfunction, or other reasons, filtering out data noise, 
> and generate reliable results at both high spatial resolution and high 
> temporal frequency with associated uncertainty estimates.
>
> Soeren, I noticed you are the author of r.series.interp. I discussed a 
> little with Luca, I agree this project is highly related to the package.
> So I am writing to ask if you are interest in mentoring this project.
> Currently I have the preliminary python code for the raster fusion 
> attached(ImageFusion_SoC.py). It was written during my master degree, 
> so it is sort of rough and haven't been re-constructed to OOP yet. But 
> it runs well for fusion MODIS and Landsat data.
>
> I attached an fusion example for NDVI[0] images.  The program is able 
> to blend Landsat TM/ETM+ NDVI image (30m) with MODIS NDVI image (250m)[1].
> The NDVI can be calculated from the combination of the red band (Band 
> 3 of Landsat TM or ETM+ multispectral imagery, or Band 1 of MODIS 
> multispectral
> imagery) and near infrared band (Band 4 of Landsat TM or ETM+ 
> multispectral imagery, or Band 2 of MODIS multispectral imagery). 
> MODIS data has been resampled to 270m to co-registered with Landsat pixels.
>
> I selected a relatively cloud free period (07/19/2002-07/29/2002) to 
> demonstrate the fusion process, the study region is Lake Tahoe region, 
> NV, USA. Both Landsat and MODIS NDVI images need to be converted to 
> ASCII file, source data can be found here[2]. Text files start with 
> "A" are daily MODIS NDVI images and "lt5ndvi_0716" is the Landsat TM 
> data. The goal of this example is to fuse daily MODIS NDVI images with 
> a Landsat NDVI images (30m) to generate images at 30 m spatial 
> resolution for everyday, using spatio-temporal cokriging method. 
> Namely, I intend to use a single high resolutions Landsat NDVI images 
> to sharpen