<div dir="ltr"><div><div><div><div><div>Hi,<br></div>        I have been struggling for a few days now with importing Linestring layers into Spatialite.<br><br></div>Everytime
 I save the layers into a sqlite file, they are automatically converted 
to MultiLinestring, even though they are perfectly normal Linestring 
files in all other formats I tested (SHP and TAB).<br><br></div>Has anybody come across this before?<br><br></div>Cheers,<br></div>Pedro<div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jan 25, 2017 at 6:00 AM,  <span dir="ltr"><<a href="mailto:grass-user-request@lists.osgeo.org" target="_blank">grass-user-request@lists.osgeo.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Send grass-user mailing list submissions to<br>
        <a href="mailto:grass-user@lists.osgeo.org">grass-user@lists.osgeo.org</a><br>
<br>
To subscribe or unsubscribe via the World Wide Web, visit<br>
        <a href="https://lists.osgeo.org/mailman/listinfo/grass-user" rel="noreferrer" target="_blank">https://lists.osgeo.org/<wbr>mailman/listinfo/grass-user</a><br>
or, via email, send a message with subject or body 'help' to<br>
        <a href="mailto:grass-user-request@lists.osgeo.org">grass-user-request@lists.<wbr>osgeo.org</a><br>
<br>
You can reach the person managing the list at<br>
        <a href="mailto:grass-user-owner@lists.osgeo.org">grass-user-owner@lists.osgeo.<wbr>org</a><br>
<br>
When replying, please edit your Subject line so it is more specific<br>
than "Re: Contents of grass-user digest..."<br>
<br>
<br>
Today's Topics:<br>
<br>
   1. Re: Archiving GPM 3hr rainrate in GRASS (Laurent C.)<br>
   2. Question to the input seed grid of i.segment (Raphael Knevels)<br>
   3. Re: Question to the input seed grid of i.segment (Moritz Lennert)<br>
   4. Re: Question to the input seed grid of i.segment (Raphael Knevels)<br>
<br>
<br>
------------------------------<wbr>------------------------------<wbr>----------<br>
<br>
Message: 1<br>
Date: Tue, 24 Jan 2017 11:39:37 -0600<br>
From: "Laurent C." <<a href="mailto:lrntct@gmail.com">lrntct@gmail.com</a>><br>
To: Veronica Andreo <<a href="mailto:veroandreo@gmail.com">veroandreo@gmail.com</a>><br>
Cc: grass list <<a href="mailto:grass-user@lists.osgeo.org">grass-user@lists.osgeo.org</a>><br>
Subject: Re: [GRASS-user] Archiving GPM 3hr rainrate in GRASS<br>
Message-ID:<br>
        <CABmXgEH7Wd==<a href="mailto:FbfB9fEDfD3Ud%2BLUSXzj1Rfhk7JpmY-aJVs1yg@mail.gmail.com">FbfB9fEDfD3Ud+<wbr>LUSXzj1Rfhk7JpmY-aJVs1yg@mail.<wbr>gmail.com</a>><br>
Content-Type: text/plain; charset=UTF-8<br>
<br>
Hello Veronica,<br>
<br>
Thanks for your interest. I've made some change to the code,<br>
especially added a HTML file. I think it was the reason why<br>
g.extension was failing.<br>
The installation works now from a local folder. For some reason it<br>
seems that g.extension fails to download the code from bitbucket.<br>
If you download the repository of clone it first, it should work.<br>
I'd be glad to hear your comments.<br>
<br>
Cheers,<br>
Laurent<br>
<br>
<br>
2017-01-22 6:56 GMT-06:00 Veronica Andreo <<a href="mailto:veroandreo@gmail.com">veroandreo@gmail.com</a>>:<br>
> Hello Laurent<br>
><br>
> w00t! This new add-on sounds very nice! I'd like to do some testing.<br>
> However, I tried to install it via g.extension and I get the following:<br>
><br>
> g.extension extension=t.rast.in.gpm<br>
> url=<a href="https://bitbucket.org/lrntct/t.rast.in.gpm" rel="noreferrer" target="_blank">https://bitbucket.org/<wbr>lrntct/t.rast.in.gpm</a><br>
> Fetching <t.rast.in.gpm> from<br>
> <<a href="https://bitbucket.org/lrntct/t.rast.in.gpm/get/default.zip" rel="noreferrer" target="_blank">https://bitbucket.org/lrntct/<wbr>t.rast.in.gpm/get/default.zip</a>> (be<br>
> patient)...<br>
> ERROR: Extension <t.rast.in.gpm> not found<br>
><br>
> Is it intended to install with g.extension?<br>
><br>
> thanks much!<br>
> Vero<br>
><br>
> 2017-01-21 1:04 GMT+01:00 Laurent C. <<a href="mailto:lrntct@gmail.com">lrntct@gmail.com</a>>:<br>
>><br>
>> Hello all,<br>
>><br>
>> I wrote a module that automatically download, import and register GPM<br>
>> IMERG maps in GRASS.<br>
>> You will need a NASA Earthdata Login to download the data. The code<br>
>> can be found here:<br>
>> <a href="https://bitbucket.org/lrntct/t.rast.in.gpm" rel="noreferrer" target="_blank">https://bitbucket.org/lrntct/<wbr>t.rast.in.gpm</a><br>
>><br>
>> For now, it is limited to IMERGHH data.<br>
>> Hope it could help people working with those data.<br>
>><br>
>> Regards,<br>
>> Laurent<br>
>><br>
>><br>
>> 2015-03-19 10:50 GMT-06:00 Laurent C. <<a href="mailto:lrntct@gmail.com">lrntct@gmail.com</a>>:<br>
>> > Hi all,<br>
>> ><br>
>> > I'm coming back to that subject because the GPM datas are finally<br>
>> > available<br>
>> > since December 2014. The original data are stored in HDF5, which is<br>
>> > supported by GDAL.<br>
>> > However, I had a problem with the geo-referencing of the data. It seems<br>
>> > that<br>
>> > the lat/long coordinates are flipped.<br>
>> > The problem seems to come from GDAL, as the HDF5 driver still don't<br>
>> > support<br>
>> > GPM data:<br>
>> > <a href="http://www.gdal.org/frmt_hdf5.html" rel="noreferrer" target="_blank">http://www.gdal.org/frmt_hdf5.<wbr>html</a><br>
>> ><br>
>> > I've actually downloaded a regional extracts the data in NetCDF from a<br>
>> > NASA<br>
>> > website, although I can't remember where exactly, as there are several<br>
>> > services. Those data suffer from the same problem of inverted<br>
>> > coordinates.<br>
>> ><br>
>> > So I used the ncpdq from NCO package to fix the NetCDF directly, and a<br>
>> > tiny<br>
>> > Python script to batch process the files :<br>
>> ><br>
>> > ###<br>
>> > #!/usr/bin/env python<br>
>> > from os import listdir<br>
>> > import subprocess<br>
>> > for input_file in listdir(main_path):<br>
>> >     output_file = input_file + '_fixed'<br>
>> >     subprocess.call(['ncpdq','-a', 'lat,lon', input_file, output_file])<br>
>> > ###<br>
>> ><br>
>> > After batch import the data in GRASS, maintaining the original name<br>
>> > including timestep, which looks like this:<br>
>> > 3B-HHR.MS.MRG.3IMERG.20140619-<wbr>S000000-E002959.0000.V03D<br>
>> ><br>
>> > A Python script to register the maps in temporal framework:<br>
>> ><br>
>> > #####<br>
>> > #!/usr/bin/env python<br>
>> > import grass.script as grass<br>
>> ><br>
>> > # retrieve the list of maps<br>
>> > maplist = grass.read_command('g.list', type = 'raster',<br>
>> >     pattern = '*IMERG*')<br>
>> ><br>
>> > # turn result in a list<br>
>> > maplist = maplist.split()<br>
>> ><br>
>> > file_name = 'gpm_timestamp.txt'<br>
>> ><br>
>> > # creating the file containing the timepstamp<br>
>> > list_file = open(file_name,'w')<br>
>> ><br>
>> > # iterate through the maps<br>
>> > for input_map in maplist:<br>
>> >     # split line to keep only the timestamp<br>
>> >     raw_ts = input_map.split('.')[4]<br>
>> >     # isolate the date<br>
>> >     raw_mapdate = raw_ts.split('-')[0]<br>
>> >     # put the date in form<br>
>> >     mapdate = raw_mapdate[:4] + '-' + raw_mapdate[4:6] + \<br>
>> >         '-' + raw_mapdate[6:]<br>
>> >     # isolate the start time<br>
>> >     raw_start_time = raw_ts.split('-')[1]<br>
>> >     # put the date in form<br>
>> >     start_time = raw_start_time[1:3] + ':' + \<br>
>> >         raw_start_time[3:5] + ':' + raw_start_time[5:]<br>
>> >     # isolate the end time<br>
>> >     raw_end_time = raw_ts.split('-')[2]<br>
>> >     # put the end time in form<br>
>> >     end_time = raw_end_time[1:3] + ':' + \<br>
>> >         raw_end_time[3:5] + ':' + raw_end_time[5:]<br>
>> >     # put timestamp in form<br>
>> >     timestamp = mapdate + ' ' + start_time + '|' + mapdate + \<br>
>> >         ' ' + end_time<br>
>> ><br>
>> >     # format the whole line<br>
>> >     line = input_map + '|' + timestamp + '\n'<br>
>> ><br>
>> >     # write line to the file<br>
>> >     list_file.write(line)<br>
>> ><br>
>> > # close the file<br>
>> > list_file.close()<br>
>> ><br>
>> > # register the maps in grass space_time dataset<br>
>> > grass.run_command('t.register'<wbr>, input = 'GPM_ZMCM', file = file_name)<br>
>> ><br>
>> > #####<br>
>> ><br>
>> ><br>
>> > Hope it will help other peoples having trouble using those data.<br>
>> ><br>
>> > Regards,<br>
>> > Laurent<br>
>> ><br>
>> ><br>
>> > 2014-11-06 5:15 GMT-06:00 maning sambale <<a href="mailto:emmanuel.sambale@gmail.com">emmanuel.sambale@gmail.com</a>>:<br>
>> >><br>
>> >> Thanks Markus.  Already registered and can access ftp.  Unfortunately,<br>
>> >> processed (L3) rainfall data will be released by Dec 2014.<br>
>> >> Will just wait then. :)<br>
>> >><br>
>> >> On Thu, Nov 6, 2014 at 4:27 PM, Markus Neteler <<a href="mailto:neteler@osgeo.org">neteler@osgeo.org</a>><br>
>> >> wrote:<br>
>> >> > On Mon, Nov 3, 2014 at 10:18 AM, maning sambale<br>
>> >> > <<a href="mailto:emmanuel.sambale@gmail.com">emmanuel.sambale@gmail.com</a>> wrote:<br>
>> >> >> Has anyone here able to archive and load GPM dataset into GRASS?  I<br>
>> >> >> was able to get TRMM netcdf in my area of interest before, but I<br>
>> >> >> can't<br>
>> >> >> find the tools to automate GPM downloads.<br>
>> >> >><br>
>> >> >> Thanks!<br>
>> >> >><br>
>> >> >> [0] <a href="http://www.nasa.gov/mission_pages/GPM/main/" rel="noreferrer" target="_blank">http://www.nasa.gov/mission_<wbr>pages/GPM/main/</a><br>
>> >> ><br>
>> >> > They state<br>
>> >> ><br>
>> >> > "All data are freely available through the NASA's Precipitation<br>
>> >> > Processing System at <a href="http://pps.gsfc.nasa.gov" rel="noreferrer" target="_blank">http://pps.gsfc.nasa.gov</a>"<br>
>> >> ><br>
>> >> > --> "Register and search for GPM and TRMM data, order custom subsets<br>
>> >> > and set up subscriptions using PPS Data Products Ordering Interface<br>
>> >> > (STORM)."<br>
>> >> ><br>
>> >> > At time the server seems to be down?<br>
>> >> ><br>
>> >> > Markus<br>
>> >><br>
>> >><br>
>> >><br>
>> >> --<br>
>> >> cheers,<br>
>> >> maning<br>
>> >> ------------------------------<wbr>------------------------<br>
>> >> "Freedom is still the most radical idea of all" -N.Branden<br>
>> >> wiki: <a href="http://esambale.wikispaces.com/" rel="noreferrer" target="_blank">http://esambale.wikispaces.<wbr>com/</a><br>
>> >> blog: <a href="http://epsg4253.wordpress.com/" rel="noreferrer" target="_blank">http://epsg4253.wordpress.com/</a><br>
>> >> ------------------------------<wbr>------------------------<br>
>> >> ______________________________<wbr>_________________<br>
>> >> grass-user mailing list<br>
>> >> <a href="mailto:grass-user@lists.osgeo.org">grass-user@lists.osgeo.org</a><br>
>> >> <a href="http://lists.osgeo.org/mailman/listinfo/grass-user" rel="noreferrer" target="_blank">http://lists.osgeo.org/<wbr>mailman/listinfo/grass-user</a><br>
>> ><br>
>> ><br>
>> ______________________________<wbr>_________________<br>
>> grass-user mailing list<br>
>> <a href="mailto:grass-user@lists.osgeo.org">grass-user@lists.osgeo.org</a><br>
>> <a href="https://lists.osgeo.org/mailman/listinfo/grass-user" rel="noreferrer" target="_blank">https://lists.osgeo.org/<wbr>mailman/listinfo/grass-user</a><br>
><br>
><br>
<br>
<br>
------------------------------<br>
<br>
Message: 2<br>
Date: Tue, 24 Jan 2017 18:42:22 +0100<br>
From: "Raphael Knevels" <<a href="mailto:raphael.knevels@uni-jena.de">raphael.knevels@uni-jena.de</a>><br>
To: <<a href="mailto:grass-user@lists.osgeo.org">grass-user@lists.osgeo.org</a>><br>
Subject: [GRASS-user] Question to the input seed grid of i.segment<br>
Message-ID: <005f01d27669$380040b0$<wbr>a800c210$@<a href="http://uni-jena.de" rel="noreferrer" target="_blank">uni-jena.de</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
Dear GRASS-community,<br>
<br>
<br>
<br>
I have to perform a multi-scale, object-oriented analysis on an image with<br>
about 93'535'000 pixels^^<br>
<br>
<br>
<br>
I'm doing the process on a server, so I need for one simple segmentation<br>
process approximately 700-800 minutes depending on the threshold. The same<br>
process in SAGA takes around 60 minutes with the use of seed points (as grid<br>
pixels). But in SAGA there is no possibility for hierarchical segmentation.<br>
Therefore, I would like to use the seed points of SAGA as Input for GRASS<br>
7.2.0 to speed up i.segment.<br>
<br>
<br>
<br>
However, I am not capable to transform the seeds of SAGA to a meaningful<br>
i.segment input. How has to look an optimal input seeds grid for GRASS?<br>
<br>
<br>
<br>
- I've already found out is that it must be an integer grid with positive<br>
seed numbers. The float-grid output of SAGA seed contains single pixels<br>
surrounded by no-data values. When I transform the SAGA seed to an integer<br>
grid and into GRASS (by (r)gdal), I have to give no data values a positive<br>
number. Negative values in the seed-grid-input lead to an error in<br>
i.segment.<br>
<br>
<br>
<br>
I would be glad for any hint and reply.<br>
<br>
<br>
<br>
Best regards<br>
<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.osgeo.org/pipermail/grass-user/attachments/20170124/105fbd3a/attachment-0001.html" rel="noreferrer" target="_blank">http://lists.osgeo.org/<wbr>pipermail/grass-user/<wbr>attachments/20170124/105fbd3a/<wbr>attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 3<br>
Date: Tue, 24 Jan 2017 19:10:45 +0100<br>
From: Moritz Lennert <<a href="mailto:mlennert@club.worldonline.be">mlennert@club.worldonline.be</a>><br>
To: <a href="mailto:grass-user@lists.osgeo.org">grass-user@lists.osgeo.org</a>,<wbr>Raphael Knevels<br>
        <<a href="mailto:raphael.knevels@uni-jena.de">raphael.knevels@uni-jena.de</a>><br>
Subject: Re: [GRASS-user] Question to the input seed grid of i.segment<br>
Message-ID: <<a href="mailto:5E0E6C7A-402B-4F07-9C4F-B5C612C7D4E0@club.worldonline.be">5E0E6C7A-402B-4F07-9C4F-<wbr>B5C612C7D4E0@club.worldonline.<wbr>be</a>><br>
Content-Type: text/plain; charset=utf-8<br>
<br>
<br>
<br>
Le 24 janvier 2017 18:42:22 GMT+01:00, Raphael Knevels <<a href="mailto:raphael.knevels@uni-jena.de">raphael.knevels@uni-jena.de</a>> a écrit :<br>
>Dear GRASS-community,<br>
><br>
><br>
><br>
>I have to perform a multi-scale, object-oriented analysis on an image<br>
>with<br>
>about 93'535'000 pixels^^<br>
><br>
><br>
><br>
>I'm doing the process on a server, so I need for one simple<br>
>segmentation<br>
>process approximately 700-800 minutes depending on the threshold.<br>
<br>
This does seem rather long. Is your computational region set to the extent and resolution of your raster ?<br>
<br>
Also try setting the memory parameter of I.segment to a higher value (depending on your server's resources).<br>
<br>
Which thresholds have you tried ?<br>
<br>
>The<br>
>same<br>
>process in SAGA takes around 60 minutes with the use of seed points (as<br>
>grid<br>
>pixels).<br>
<br>
Which segmentation algorithm do you use in SAGA ?<br>
<br>
>But in SAGA there is no possibility for hierarchical<br>
>segmentation.<br>
>Therefore, I would like to use the seed points of SAGA as Input for<br>
>GRASS<br>
>7.2.0 to speed up i.segment.<br>
><br>
><br>
><br>
>However, I am not capable to transform the seeds of SAGA to a<br>
>meaningful<br>
>i.segment input. How has to look an optimal input seeds grid for GRASS?<br>
><br>
><br>
><br>
>- I've already found out is that it must be an integer grid with<br>
>positive<br>
>seed numbers. The float-grid output of SAGA seed contains single pixels<br>
>surrounded by no-data values. When I transform the SAGA seed to an<br>
>integer<br>
>grid and into GRASS (by (r)gdal), I have to give no data values a<br>
>positive<br>
>number. Negative values in the seed-grid-input lead to an error in<br>
>i.segment.<br>
<br>
Seeds in i.segment have to be polygons not points. These polygons are represented by identical positive integer values (= IDs) in adjacent pixels, and they have to cover the entire region. When used as seeds for a segmentation, these polygons are the further merged.<br>
<br>
I don't really understand what your seed points represent, but unless they have a semantic meaning related to the objects you are trying to identify, I'm not sure they are really relevant.<br>
<br>
You could try using the brand new i.superpixels.slic add-on to create superpixels which you can then use as seeds.<br>
<br>
Moritz<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 4<br>
Date: Tue, 24 Jan 2017 20:40:57 +0100<br>
From: "Raphael Knevels" <<a href="mailto:raphael.knevels@uni-jena.de">raphael.knevels@uni-jena.de</a>><br>
To: "'Moritz Lennert'" <<a href="mailto:mlennert@club.worldonline.be">mlennert@club.worldonline.be</a>><wbr>,<br>
        <<a href="mailto:grass-user@lists.osgeo.org">grass-user@lists.osgeo.org</a>><br>
Subject: Re: [GRASS-user] Question to the input seed grid of i.segment<br>
Message-ID: <007201d27679$c93c2c50$<wbr>5bb484f0$@<a href="http://uni-jena.de" rel="noreferrer" target="_blank">uni-jena.de</a>><br>
Content-Type: text/plain;       charset="UTF-8"<br>
<br>
Thanks for the quick response :-)<br>
<br>
The extent of my region is also the extent of my imagery-group. For i.segment I used as memory 10240 MB with a threshold of 0.25.<br>
<br>
In SAGA I used at first Seed Generation (Band Width of 18, but I also varied this parameter) for producing the Seed Output. The Seed Output is a raster with floating point values. Moreover, the Seed Output contains single pixels distributed over the hole area. The "space" between those pixels is "no data". The segmentation is then computed by Seeded Region Growing with the seed grid as input.<br>
<br>
"Seeds in i.segment have to be polygons not points. These polygons are represented by identical positive integer values (= IDs) in adjacent pixels, and they have to cover the entire region. When used as seeds for a segmentation, these polygons are the further merged."<br>
-> alright. That means, I definitely must convert the no data values in the SAGA Seed Output to zero or any other integer number.<br>
Meanwhile, I also tried the segmentation result of SAGA Seeded Region Growing as Seeds for GRASS - this works...<br>
<br>
<br>
" You could try using the brand new i.superpixels.slic add-on to create superpixels which you can then use as seeds."<br>
-> I could successfully install and open it ("g.extension i.superpixels.slic", GRASS 7.2.0). However, when I run the tool with default settings, GRASS gives a problem message and finishs the process.<br>
<br>
Raphael<br>
<br>
-----Ursprüngliche Nachricht-----<br>
Von: Moritz Lennert [mailto:<a href="mailto:mlennert@club.worldonline.be">mlennert@club.<wbr>worldonline.be</a>]<br>
Gesendet: Dienstag, 24. Januar 2017 19:11<br>
An: <a href="mailto:grass-user@lists.osgeo.org">grass-user@lists.osgeo.org</a>; Raphael Knevels<br>
Betreff: Re: [GRASS-user] Question to the input seed grid of i.segment<br>
<br>
<br>
<br>
Le 24 janvier 2017 18:42:22 GMT+01:00, Raphael Knevels <<a href="mailto:raphael.knevels@uni-jena.de">raphael.knevels@uni-jena.de</a>> a écrit :<br>
>Dear GRASS-community,<br>
><br>
><br>
><br>
>I have to perform a multi-scale, object-oriented analysis on an image<br>
>with about 93'535'000 pixels^^<br>
><br>
><br>
><br>
>I'm doing the process on a server, so I need for one simple<br>
>segmentation process approximately 700-800 minutes depending on the<br>
>threshold.<br>
<br>
This does seem rather long. Is your computational region set to the extent and resolution of your raster ?<br>
<br>
Also try setting the memory parameter of I.segment to a higher value (depending on your server's resources).<br>
<br>
Which thresholds have you tried ?<br>
<br>
>The<br>
>same<br>
>process in SAGA takes around 60 minutes with the use of seed points (as<br>
>grid pixels).<br>
<br>
Which segmentation algorithm do you use in SAGA ?<br>
<br>
>But in SAGA there is no possibility for hierarchical segmentation.<br>
>Therefore, I would like to use the seed points of SAGA as Input for<br>
>GRASS<br>
>7.2.0 to speed up i.segment.<br>
><br>
><br>
><br>
>However, I am not capable to transform the seeds of SAGA to a<br>
>meaningful i.segment input. How has to look an optimal input seeds grid<br>
>for GRASS?<br>
><br>
><br>
><br>
>- I've already found out is that it must be an integer grid with<br>
>positive seed numbers. The float-grid output of SAGA seed contains<br>
>single pixels surrounded by no-data values. When I transform the SAGA<br>
>seed to an integer grid and into GRASS (by (r)gdal), I have to give no<br>
>data values a positive number. Negative values in the seed-grid-input<br>
>lead to an error in i.segment.<br>
<br>
Seeds in i.segment have to be polygons not points. These polygons are represented by identical positive integer values (= IDs) in adjacent pixels, and they have to cover the entire region. When used as seeds for a segmentation, these polygons are the further merged.<br>
<br>
I don't really understand what your seed points represent, but unless they have a semantic meaning related to the objects you are trying to identify, I'm not sure they are really relevant.<br>
<br>
You could try using the brand new i.superpixels.slic add-on to create superpixels which you can then use as seeds.<br>
<br>
Moritz<br>
<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Subject: Digest Footer<br>
<br>
______________________________<wbr>_________________<br>
grass-user mailing list<br>
<a href="mailto:grass-user@lists.osgeo.org">grass-user@lists.osgeo.org</a><br>
<a href="https://lists.osgeo.org/mailman/listinfo/grass-user" rel="noreferrer" target="_blank">https://lists.osgeo.org/<wbr>mailman/listinfo/grass-user</a><br>
<br>
------------------------------<br>
<br>
End of grass-user Digest, Vol 129, Issue 35<br>
******************************<wbr>*************<br>
</blockquote></div><br></div></div>