<div dir="ltr">Subject: Re: [GRASS-user] v.what.vect never ends, SQLite warning <br><div><br></div><div>Hi Everyone,</div><div>I think I figured out the problem.</div><div>I found that the problem was only the size or number of attributes in the point layer when I dropped and reduced the attributes it worked very fast and with no problem.</div><div>I am interested to know the limitations in GRASS GIS in terms of the number of features or attributes, if there is any reference, please let me know.</div><div><br></div><div>Thanks,</div><div><br></div><div>Mehrdad</div><div><br></div></div><div hspace="streak-pt-mark" style="max-height:1px"><img alt="" style="width:0px;max-height:0px;overflow:hidden" src="https://mailfoogae.appspot.com/t?sender=admFyZWRpQGdtYWlsLmNvbQ%3D%3D&type=zerocontent&guid=7e4ee802-6141-4738-b1fa-c60168218119"><font color="#ffffff" size="1">ᐧ</font></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, May 22, 2019 at 7:07 PM <<a href="mailto:grass-user-request@lists.osgeo.org">grass-user-request@lists.osgeo.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Send grass-user mailing list submissions to<br>
<a href="mailto:grass-user@lists.osgeo.org" target="_blank">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/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" target="_blank">grass-user-request@lists.osgeo.org</a><br>
<br>
You can reach the person managing the list at<br>
<a href="mailto:grass-user-owner@lists.osgeo.org" target="_blank">grass-user-owner@lists.osgeo.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: v.what.vect never ends, SQLite warning (Mehrdad Varedi)<br>
2. Average height over catchment in grass gis (Rengifo Ortega)<br>
3. Re: importing and cleaning overlapping polygons that are<br>
supposed to overlap (Moritz Lennert)<br>
4. Re: importing and cleaning overlapping polygons that are<br>
supposed to overlap (Veronica Andreo)<br>
<br>
<br>
----------------------------------------------------------------------<br>
<br>
Message: 1<br>
Date: Wed, 22 May 2019 16:20:21 -0400<br>
From: Mehrdad Varedi <<a href="mailto:varedi@gmail.com" target="_blank">varedi@gmail.com</a>><br>
To: grass-user <<a href="mailto:grass-user@lists.osgeo.org" target="_blank">grass-user@lists.osgeo.org</a>><br>
Subject: Re: [GRASS-user] v.what.vect never ends, SQLite warning<br>
Message-ID:<br>
<<a href="mailto:CA%2BF3BSDW5cVJLFonj%2BSoKamo59K0XQCuW9QS1MDM9GYgTZoouw@mail.gmail.com" target="_blank">CA+F3BSDW5cVJLFonj+SoKamo59K0XQCuW9QS1MDM9GYgTZoouw@mail.gmail.com</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
Hi Everyone,<br>
When I try v.what.vect on a point layer and the output of a v.voronoi,<br>
after around an hour I begin getting the warnings that apparently are<br>
because of an SQLite database lock.<br>
<br>
This is not what happens with v.what.vect only.<br>
When exporting the layer to shapefile or any other format it happens too.<br>
The point layer is not very big. it has 275,000 records and each has 350<br>
features (they are mostly double precision). The same happens with v.color<br>
on this layer.<br>
<br>
I have read feedback like, the SQLite doesn't like concurrent access on the<br>
same table, although I have restarted the computer, run only grass or tried<br>
to run it from R within GRASS and no other connection to that database<br>
existed, although the process takes forever and I begin getting the warning<br>
"Waiting for XXX seconds"<br>
<br>
Do you know how can I accelerate the processing or make it work?<br>
<br>
FYI, the CPU is not very busy more than 15-20% of its total capacity and<br>
the memory of 16GB is usually half free. The writing on disk is very<br>
minimal when it is working before the SQLite lock warning.<br>
<br>
Kind regards,<br>
<br>
Mehrdad<br>
<br>
ᐧ<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.osgeo.org/pipermail/grass-user/attachments/20190522/a2ed69a6/attachment-0001.html" rel="noreferrer" target="_blank">http://lists.osgeo.org/pipermail/grass-user/attachments/20190522/a2ed69a6/attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 2<br>
Date: Wed, 22 May 2019 21:29:38 +0000 (UTC)<br>
From: Rengifo Ortega <<a href="mailto:rengifoo@yahoo.de" target="_blank">rengifoo@yahoo.de</a>><br>
To: <a href="mailto:grass-user@lists.osgeo.org" target="_blank">grass-user@lists.osgeo.org</a><br>
Subject: [GRASS-user] Average height over catchment in grass gis<br>
Message-ID: <<a href="mailto:2011043303.7503049.1558560578039@mail.yahoo.com" target="_blank">2011043303.7503049.1558560578039@mail.yahoo.com</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
Dear users I am writting you here with the hope of getting some ideas about how to caculate what Kirsten Hennrich et al., refers to as average catchment height (Ha) I found this infomation in the proceedings of an international conference called regionalisation of hydrology. <br>
In page 184, he says that it is possible to calculate Ha using r.statistics in GRASS GIS (IAHS publication no. 254). <br>
I have been using sofar SAGA GIS to do the job. But recently I am experiencing some memory issues with SAGA GIS. In the old versions of SAGA GIS this calculation was named catchment height. The new versions of SAGA GIS require that the user calculate the mean over catchment (MoC) first. Thereafter is MoC substrated from the original DTM. The product of this is the average catchment height or simply catchment height. <br>
Have someone in this group used GRASS GIS to calculate Catchment height in GRASS GIS. Any hint will be appreciated.<br>
Best regardsRengifo Ortega<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.osgeo.org/pipermail/grass-user/attachments/20190522/49e1a001/attachment-0001.html" rel="noreferrer" target="_blank">http://lists.osgeo.org/pipermail/grass-user/attachments/20190522/49e1a001/attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 3<br>
Date: Thu, 23 May 2019 00:15:16 +0200<br>
From: Moritz Lennert <<a href="mailto:mlennert@club.worldonline.be" target="_blank">mlennert@club.worldonline.be</a>><br>
To: Veronica Andreo <<a href="mailto:veroandreo@gmail.com" target="_blank">veroandreo@gmail.com</a>><br>
Cc: Markus Metz <<a href="mailto:markus.metz.giswork@gmail.com" target="_blank">markus.metz.giswork@gmail.com</a>>, grass-user<br>
<<a href="mailto:grass-user@lists.osgeo.org" target="_blank">grass-user@lists.osgeo.org</a>>, Micha Silver <<a href="mailto:tsvibar@gmail.com" target="_blank">tsvibar@gmail.com</a>><br>
Subject: Re: [GRASS-user] importing and cleaning overlapping polygons<br>
that are supposed to overlap<br>
Message-ID: <20190523001516.07cd6c77@moritz-ulb><br>
Content-Type: text/plain; charset=UTF-8<br>
<br>
Le Wed, 22 May 2019 19:25:19 +0200,<br>
Veronica Andreo <<a href="mailto:veroandreo@gmail.com" target="_blank">veroandreo@gmail.com</a>> a écrit :<br>
<br>
> Hi Markus,<br>
> <br>
> Thanks for the explanation. It is possible to import topologically<br>
> incorrect vectors, but not create them within GRASS. So, as a<br>
> solution to my problem, I rather create (potentially overlapping)<br>
> buffers outside GRASS and import them with -c in v.in.ogr to use<br>
> v.rast.stats with no loss of areas, or follow the procedure that you<br>
> described earlier in the thread.<br>
<br>
You can also have a look at the v.rast.bufferstats addon.<br>
<br>
Moritz<br>
<br>
> <br>
> Cheers,<br>
> Vero<br>
> <br>
> El mié., 22 may. 2019 a las 18:48, Markus Metz (<<br>
> <a href="mailto:markus.metz.giswork@gmail.com" target="_blank">markus.metz.giswork@gmail.com</a>>) escribió: <br>
> <br>
> ><br>
> ><br>
> > On Wed, May 22, 2019 at 3:11 PM Veronica Andreo<br>
> > <<a href="mailto:veroandreo@gmail.com" target="_blank">veroandreo@gmail.com</a>> wrote: <br>
> > ><br>
> > > Dear all,<br>
> > ><br>
> > > thanks again for your answers. I found an easier way, use -c flag<br>
> > > in <br>
> > v.in.ogr seems to not build topology of overlapping areas and then<br>
> > v.rast.stats does not complain. <br>
> > ><br>
> > > However, if one builds buffer areas for points within GRASS,<br>
> > > i.e., using <br>
> > v.buffer, the problem appears again when buffer areas overlap,<br>
> > which it's pretty common when creating buffers around neighbouring<br>
> > points. Then, to get zonal stats for those areas the approach<br>
> > suggested by Markus Metz should be followed. I believe it is a bit<br>
> > of an overkill for such a common task in GIS. Couldn't v.buffer<br>
> > have a -c flag as v.in.ogr so when overlapping of buffer areas is<br>
> > fine the topology is not built and one would get just one area per<br>
> > input point? Would that be possible?<br>
> ><br>
> > In short, no.<br>
> ><br>
> > The reason is that with a topological vector model, areas are<br>
> > constructed from boundaries and centroids. If you use the -c flag<br>
> > of v.in.ogr and there are polygons that overlap to a large degree<br>
> > or completely, it is not possible to find a centroid for each<br>
> > topological area, i.e. the overlapping input polygons can not be<br>
> > properly represented with a topological model when using the -c<br>
> > flag. As soon as you get incorrect boundaries and/or duplicate<br>
> > centroids when building topology, results are wrong.<br>
> ><br>
> > Markus M<br>
> > <br>
> > ><br>
> > > cheers,<br>
> > > Vero<br>
> > ><br>
> > ><br>
> > ><br>
> > > El jue., 16 may. 2019 a las 11:27, Moritz Lennert (<<br>
> > <a href="mailto:mlennert@club.worldonline.be" target="_blank">mlennert@club.worldonline.be</a>>) escribió: <br>
> > >><br>
> > >> On 16/05/19 03:11, Veronica Andreo wrote: <br>
> > >> > Dear all,<br>
> > >> ><br>
> > >> > thanks for the answers...<br>
> > >> ><br>
> > >> > @Madi, I know, but that's how I got the data from a colleague<br>
> > >> > using SaTScan to get cluster sizes.<br>
> > >> ><br>
> > >> > So, these "clusters" are 3, they are represented by circular<br>
> > >> > areas <br>
> > and 2 <br>
> > >> > of them overlap, and it is just fine that they overlap. I just<br>
> > >> > want <br>
> > one <br>
> > >> > centroid per area to be able to get one value per original<br>
> > >> > area.<br>
> > >> ><br>
> > >> > I tested your solution, @Micha (thanks much for your time!),<br>
> > >> > but it gives me 4 values, and I need 3. Moreover, I can no<br>
> > >> > longer recognize which polygon is which since v.db.select for<br>
> > >> > layer 3 reports cats <br>
> > from 1 <br>
> > >> > to 4, but d.vect shows something different (I'd assume 2/3 has<br>
> > >> > become 4?). See screenshot below. <br>
> > >><br>
> > >> To see the cat values of layer 3 you have to indicate that layer<br>
> > >> in the label_layer parameter (Labels tab).<br>
> > >><br>
> > >> You can also see the correspondance between the two layers with<br>
> > >><br>
> > >> v.category polys_3layers op=print layer=1,3<br>
> > >> <br>
> > >> ><br>
> > >> > So, is it possible somehow to keep my 3 original polygons? And<br>
> > >> > how <br>
> > can I <br>
> > >> > get raster values for my original 3 polygons in GRASS? Or is<br>
> > >> > it that this is not allowed by topology? <br>
> > >><br>
> > >> This depends on how you want to get raster values. If<br>
> > >> v.what.rast at the location of the centroid is all you need than<br>
> > >> Micha's solution should <br>
> > work. <br>
> > >><br>
> > >> If you need v.rast.stats then you either have to use Markus'<br>
> > >> suggestion, or you use Micha's approach running v.rast.stats on<br>
> > >> layer three and then use some magic to transform the output of<br>
> > >> the above v.category call to a correspondance table between<br>
> > >> layer. Something like this<br>
> > >><br>
> > >> import grass.script as g<br>
> > >> for feature in g.read_command('v.category',<br>
> > >> input_='polys_3layers',<br>
> > >> op='print',<br>
> > >> layer=[3,1]).splitlines():<br>
> > >> cat1 = feature.split('|')[0]<br>
> > >> cats2 = feature.split('|')[1].split('/')<br>
> > >> for cat2 in cats2:<br>
> > >> print cat1, cat2<br>
> > >><br>
> > >> This correspondance table could then be used to aggregate the<br>
> > >> raster stats per (original) polygon in SQL. This could be the<br>
> > >> easily put into an addon module.<br>
> > >><br>
> > >> Moritz<br>
> > >> <br>
> > > _______________________________________________<br>
> > > grass-user mailing list<br>
> > > <a href="mailto:grass-user@lists.osgeo.org" target="_blank">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/mailman/listinfo/grass-user</a> <br>
> > <br>
<br>
<br>
<br>
-- <br>
Département Géosciences, Environnement et Société Université Libre de<br>
Bruxelles Bureau: S.DB.6.138<br>
CP 130/03<br>
Av. F.D. Roosevelt 50<br>
1050 Bruxelles<br>
Belgique<br>
<br>
tél. + 32 2 650.68.12 / 68.11 (secr.)<br>
fax + 32 2 650.68.30 <br>
<br>
<br>
------------------------------<br>
<br>
Message: 4<br>
Date: Wed, 22 May 2019 20:06:22 -0300<br>
From: Veronica Andreo <<a href="mailto:veroandreo@gmail.com" target="_blank">veroandreo@gmail.com</a>><br>
To: Moritz Lennert <<a href="mailto:mlennert@club.worldonline.be" target="_blank">mlennert@club.worldonline.be</a>><br>
Cc: Markus Metz <<a href="mailto:markus.metz.giswork@gmail.com" target="_blank">markus.metz.giswork@gmail.com</a>>, grass-user<br>
<<a href="mailto:grass-user@lists.osgeo.org" target="_blank">grass-user@lists.osgeo.org</a>>, Micha Silver <<a href="mailto:tsvibar@gmail.com" target="_blank">tsvibar@gmail.com</a>><br>
Subject: Re: [GRASS-user] importing and cleaning overlapping polygons<br>
that are supposed to overlap<br>
Message-ID:<br>
<<a href="mailto:CAAMki4GAFCMrQL-wWCFNFPjwnezv9MSevcyZPuYLDp1EBDygag@mail.gmail.com" target="_blank">CAAMki4GAFCMrQL-wWCFNFPjwnezv9MSevcyZPuYLDp1EBDygag@mail.gmail.com</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
Hi Moritz<br>
<br>
Thanks for the heads-up! Yes, for overlapping buffers v.rast.bufferstats<br>
seems just perfect! IIUC, it does exactly what MM was explaining. Great!<br>
<br>
Thanks again! And thanks Stefan for the add-on!<br>
<br>
Vero<br>
<br>
<br>
El mié., 22 may. 2019 19:30, Moritz Lennert <<a href="mailto:mlennert@club.worldonline.be" target="_blank">mlennert@club.worldonline.be</a>><br>
escribió:<br>
<br>
> Le Wed, 22 May 2019 19:25:19 +0200,<br>
> Veronica Andreo <<a href="mailto:veroandreo@gmail.com" target="_blank">veroandreo@gmail.com</a>> a écrit :<br>
><br>
> > Hi Markus,<br>
> ><br>
> > Thanks for the explanation. It is possible to import topologically<br>
> > incorrect vectors, but not create them within GRASS. So, as a<br>
> > solution to my problem, I rather create (potentially overlapping)<br>
> > buffers outside GRASS and import them with -c in v.in.ogr to use<br>
> > v.rast.stats with no loss of areas, or follow the procedure that you<br>
> > described earlier in the thread.<br>
><br>
> You can also have a look at the v.rast.bufferstats addon.<br>
><br>
> Moritz<br>
><br>
> ><br>
> > Cheers,<br>
> > Vero<br>
> ><br>
> > El mié., 22 may. 2019 a las 18:48, Markus Metz (<<br>
> > <a href="mailto:markus.metz.giswork@gmail.com" target="_blank">markus.metz.giswork@gmail.com</a>>) escribió:<br>
> ><br>
> > ><br>
> > ><br>
> > > On Wed, May 22, 2019 at 3:11 PM Veronica Andreo<br>
> > > <<a href="mailto:veroandreo@gmail.com" target="_blank">veroandreo@gmail.com</a>> wrote:<br>
> > > ><br>
> > > > Dear all,<br>
> > > ><br>
> > > > thanks again for your answers. I found an easier way, use -c flag<br>
> > > > in<br>
> > > v.in.ogr seems to not build topology of overlapping areas and then<br>
> > > v.rast.stats does not complain.<br>
> > > ><br>
> > > > However, if one builds buffer areas for points within GRASS,<br>
> > > > i.e., using<br>
> > > v.buffer, the problem appears again when buffer areas overlap,<br>
> > > which it's pretty common when creating buffers around neighbouring<br>
> > > points. Then, to get zonal stats for those areas the approach<br>
> > > suggested by Markus Metz should be followed. I believe it is a bit<br>
> > > of an overkill for such a common task in GIS. Couldn't v.buffer<br>
> > > have a -c flag as v.in.ogr so when overlapping of buffer areas is<br>
> > > fine the topology is not built and one would get just one area per<br>
> > > input point? Would that be possible?<br>
> > ><br>
> > > In short, no.<br>
> > ><br>
> > > The reason is that with a topological vector model, areas are<br>
> > > constructed from boundaries and centroids. If you use the -c flag<br>
> > > of v.in.ogr and there are polygons that overlap to a large degree<br>
> > > or completely, it is not possible to find a centroid for each<br>
> > > topological area, i.e. the overlapping input polygons can not be<br>
> > > properly represented with a topological model when using the -c<br>
> > > flag. As soon as you get incorrect boundaries and/or duplicate<br>
> > > centroids when building topology, results are wrong.<br>
> > ><br>
> > > Markus M<br>
> > ><br>
> > > ><br>
> > > > cheers,<br>
> > > > Vero<br>
> > > ><br>
> > > ><br>
> > > ><br>
> > > > El jue., 16 may. 2019 a las 11:27, Moritz Lennert (<<br>
> > > <a href="mailto:mlennert@club.worldonline.be" target="_blank">mlennert@club.worldonline.be</a>>) escribió:<br>
> > > >><br>
> > > >> On 16/05/19 03:11, Veronica Andreo wrote:<br>
> > > >> > Dear all,<br>
> > > >> ><br>
> > > >> > thanks for the answers...<br>
> > > >> ><br>
> > > >> > @Madi, I know, but that's how I got the data from a colleague<br>
> > > >> > using SaTScan to get cluster sizes.<br>
> > > >> ><br>
> > > >> > So, these "clusters" are 3, they are represented by circular<br>
> > > >> > areas<br>
> > > and 2<br>
> > > >> > of them overlap, and it is just fine that they overlap. I just<br>
> > > >> > want<br>
> > > one<br>
> > > >> > centroid per area to be able to get one value per original<br>
> > > >> > area.<br>
> > > >> ><br>
> > > >> > I tested your solution, @Micha (thanks much for your time!),<br>
> > > >> > but it gives me 4 values, and I need 3. Moreover, I can no<br>
> > > >> > longer recognize which polygon is which since v.db.select for<br>
> > > >> > layer 3 reports cats<br>
> > > from 1<br>
> > > >> > to 4, but d.vect shows something different (I'd assume 2/3 has<br>
> > > >> > become 4?). See screenshot below.<br>
> > > >><br>
> > > >> To see the cat values of layer 3 you have to indicate that layer<br>
> > > >> in the label_layer parameter (Labels tab).<br>
> > > >><br>
> > > >> You can also see the correspondance between the two layers with<br>
> > > >><br>
> > > >> v.category polys_3layers op=print layer=1,3<br>
> > > >><br>
> > > >> ><br>
> > > >> > So, is it possible somehow to keep my 3 original polygons? And<br>
> > > >> > how<br>
> > > can I<br>
> > > >> > get raster values for my original 3 polygons in GRASS? Or is<br>
> > > >> > it that this is not allowed by topology?<br>
> > > >><br>
> > > >> This depends on how you want to get raster values. If<br>
> > > >> v.what.rast at the location of the centroid is all you need than<br>
> > > >> Micha's solution should<br>
> > > work.<br>
> > > >><br>
> > > >> If you need v.rast.stats then you either have to use Markus'<br>
> > > >> suggestion, or you use Micha's approach running v.rast.stats on<br>
> > > >> layer three and then use some magic to transform the output of<br>
> > > >> the above v.category call to a correspondance table between<br>
> > > >> layer. Something like this<br>
> > > >><br>
> > > >> import grass.script as g<br>
> > > >> for feature in g.read_command('v.category',<br>
> > > >> input_='polys_3layers',<br>
> > > >> op='print',<br>
> > > >> layer=[3,1]).splitlines():<br>
> > > >> cat1 = feature.split('|')[0]<br>
> > > >> cats2 = feature.split('|')[1].split('/')<br>
> > > >> for cat2 in cats2:<br>
> > > >> print cat1, cat2<br>
> > > >><br>
> > > >> This correspondance table could then be used to aggregate the<br>
> > > >> raster stats per (original) polygon in SQL. This could be the<br>
> > > >> easily put into an addon module.<br>
> > > >><br>
> > > >> Moritz<br>
> > > >><br>
> > > > _______________________________________________<br>
> > > > grass-user mailing list<br>
> > > > <a href="mailto:grass-user@lists.osgeo.org" target="_blank">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/mailman/listinfo/grass-user</a><br>
> > ><br>
><br>
><br>
><br>
> --<br>
> Département Géosciences, Environnement et Société Université Libre de<br>
> Bruxelles Bureau: S.DB.6.138<br>
> CP 130/03<br>
> Av. F.D. Roosevelt 50<br>
> 1050 Bruxelles<br>
> Belgique<br>
><br>
> tél. + 32 2 650.68.12 / 68.11 (secr.)<br>
> fax + 32 2 650.68.30<br>
><br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.osgeo.org/pipermail/grass-user/attachments/20190522/6f32132a/attachment.html" rel="noreferrer" target="_blank">http://lists.osgeo.org/pipermail/grass-user/attachments/20190522/6f32132a/attachment.html</a>><br>
<br>
------------------------------<br>
<br>
Subject: Digest Footer<br>
<br>
_______________________________________________<br>
grass-user mailing list<br>
<a href="mailto:grass-user@lists.osgeo.org" target="_blank">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/mailman/listinfo/grass-user</a><br>
<br>
------------------------------<br>
<br>
End of grass-user Digest, Vol 157, Issue 33<br>
*******************************************<br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature">Mehrdad Varedi</div>