I have some tif files, i want to extract the spatical data from then what should i do. I am now using GRASS 6.2 and i have done the following <br> <br>r.in.gdal input=xxx.tif output=yy<br><br>AN error message<br><br>then i use <br>r.in.gdal -o input=xxx.tif output=yy<br><br>it creats three files in my mapset by the name of yy.red,yy.blue,yy.green, what about spatical data.<br><br><br>Thanks,<br> Pawan<br><br><b><i>grassuser-request@grass.itc.it</i></b> wrote:<blockquote class="replbq" style="border-left: 2px solid rgb(16, 16, 255); margin-left: 5px; padding-left: 5px;"> Send grassuser mailing list submissions to<br> grassuser@grass.itc.it<br><br>To subscribe or unsubscribe via the World Wide Web, visit<br> http://grass.itc.it/mailman/listinfo/grassuser<br>or, via email, send a message with subject or body 'help' to<br> grassuser-request@grass.itc.it<br><br>You can reach the person managing the list at<br> grassuser-owner@grass.itc.it<br><br>When
replying, please edit your Subject line so it is more specific<br>than "Re: Contents of grassuser digest..."<br><br><br>Today's Topics:<br><br> 1. linear referencing system - has anyone used it? (Lindsay Mico)<br> 2. Re: gis.m fails in latest cvs and black images from nivz<br> (Maciej Sieczka)<br> 3. Re: gis.m fails in latest cvs and black images from nivz<br> ( Carlos "Gu?no" Grohmann )<br> 4. New Mac OS X application build option (William Kyngesburye)<br> 5. Re: linear referencing system - has anyone used it? (Trevor Wiens)<br> 6. Re: [GRASS-dev] New Mac OS X application build option<br> (Michael Barton)<br> 7. Re: r.in.srtm help, again (Hamish)<br> 8. Re: ascii to dem (Hamish)<br> 9. Datum transformations (Jose Gomez-Dans)<br><br><br>----------------------------------------------------------------------<br><br>Message: 1<br>Date: Wed, 14 Mar 2007 12:37:28 -0800<br>From: "Lindsay Mico" <lindsaymico@hotmail.com><br>Subject: [GRASS-user]
linear referencing system - has anyone used it?<br>To: grassuser@grass.itc.it<br>Message-ID: <BAY121-F4D714BD180BC006550BE5A3730@phx.gbl><br>Content-Type: text/plain; format=flowed<br><br>I posted a question a few weeks ago about the linear referencing system. <br>Has anyone actually used it to make new maps from field data? Unfortunately <br>the developer of this function (Radim Blazek) no longer works on Grass. <br>Below is a copy of my original question.<br><br>Thanks and cheers.<br><br><br>Fellow GRASS users,<br><br>I would like to build a new point data layer from a large database of stream<br>surveys which have 2 pieces of spatial info:<br><br>1) an LLID number for that stream<br>2) distance from the start of that stream<br><br>Based on what I have seen, I would use the linear referencing system<br>modules. I am not sure if I need to build a new reference layer as I have a<br>stream layer with the LLID info already in it. Additionally, I could not<br>find an
example of how v.lrs.segment works in practice. I have attempted to<br>summarize things as I understand it to help make it easier to answer my<br>questions. As I understand it the input parameters for v.lrs.segment would<br>be as follows:<br><br>1) input= the stream layer with the associated LLID info<br>2) output = the name of the output layer<br>3) llayer = whether it is a point or line (is it 1 for line and 0 for<br>point?)<br>4) rsdriver = I don't know what this means<br>5) rsdatabase = the location of the file with the LLID # and distance<br>6) rstable = the name of the file which has the LLID number and distance?<br>will it automatically add in the other data in the database? Or do I do<br>that later using a spreadsheet program on the .dbf<br><br>As I am still learning how to do this, I expect I will have more questions<br>in the future. Hopefully this will be of use to others as well. Many<br>thanks in advance. Cheers.<br><br><br><br>Lindsay
Mico<br>Environmental Consultant<br>Demeter Design LLC<br>(503) 368-7195<br>http://demeterdesign.net<br>"Thoughtful Planning is the Surest Investment"<br><br><br><br><br>------------------------------<br><br>Message: 2<br>Date: Wed, 14 Mar 2007 22:46:19 +0100<br>From: Maciej Sieczka <tutey@o2.pl><br>Subject: Re: [GRASS-user] gis.m fails in latest cvs and black images<br> from nivz<br>To: "Carlos \"Gu?no\" Grohmann" <carlos.grohmann@gmail.com><br>Cc: grass user <grassuser@grass.itc.it><br>Message-ID: <45F86D2B.1000502@o2.pl><br>Content-Type: text/plain; charset=ISO-8859-2<br><br>Carlos "Guâno" Grohmann wrote:<br>> Hello all.<br>> <br>> I just compiled the latest cvs (Ubuntu 6.10), and gis.m fails with<br>> "child proccess exited abnormally"... just after I select the<br>> Location/Mapaset for the session.<br><br>I don't confirm, using fresh 6.3 CVS on Ubuntu 6.06.1 Dapper<br><br>> Also, when in nviz (both with 6.2.1 and with 6.3cvs), when I try
to<br>> save the view as an image (ppm, tiff, or max.res. ppm), all I get is a<br>> black image.<br><br>For me saving to ppm and tiff work OK. Saving to max res ppm however<br>results in over 40 black or corrupted ppms, some of them ahving the<br>'tmp' in their name, like if they were some remainments of temporary files.<br><br>Anyway, I cannot confirm other of your problems.<br><br>For a wild guess, I tried changing my shell from bash to dash, wchich<br>Ubuntu 6.10 uses by default. This doesn't brake anything either. Both<br>bash and dash let the startup gui, gis.m and nviz run fine.<br><br>Maciek<br><br><br><br>------------------------------<br><br>Message: 3<br>Date: Wed, 14 Mar 2007 19:06:14 -0300<br>From: " Carlos \"Gu?no\" Grohmann " <carlos.grohmann@gmail.com><br>Subject: Re: [GRASS-user] gis.m fails in latest cvs and black images<br> from nivz<br>Cc: "grass user" <grassuser@grass.itc.it><br>Message-ID:<br>
<bd07447b0703141506s70eee005x7cabed633b608351@mail.gmail.com><br>Content-Type: text/plain; charset=ISO-8859-1; format=flowed<br><br>Well I did a completely fresh install (removed old grass, downloaded<br>again.. etc) and now its working, except for the ppm/tiff export from<br>NVIZ. still only black images.<br><br>Carlos<br><br><br><br>On 3/14/07, Maciej Sieczka <tutey@o2.pl> wrote:<br>> Carlos "Guâno" Grohmann wrote:<br>> > Hello all.<br>> ><br>> > I just compiled the latest cvs (Ubuntu 6.10), and gis.m fails with<br>> > "child proccess exited abnormally"... just after I select the<br>> > Location/Mapaset for the session.<br>><br>> I don't confirm, using fresh 6.3 CVS on Ubuntu 6.06.1 Dapper<br>><br>> > Also, when in nviz (both with 6.2.1 and with 6.3cvs), when I try to<br>> > save the view as an image (ppm, tiff, or max.res. ppm), all I get is a<br>> > black image.<br>><br>> For me saving to ppm and tiff
work OK. Saving to max res ppm however<br>> results in over 40 black or corrupted ppms, some of them ahving the<br>> 'tmp' in their name, like if they were some remainments of temporary files.<br>><br>> Anyway, I cannot confirm other of your problems.<br>><br>> For a wild guess, I tried changing my shell from bash to dash, wchich<br>> Ubuntu 6.10 uses by default. This doesn't brake anything either. Both<br>> bash and dash let the startup gui, gis.m and nviz run fine.<br>><br>> Maciek<br>><br><br><br>-- <br>+-----------------------------------------------------------+<br> Carlos Henrique Grohmann - Guano<br> Geologist M.Sc - Doctorate Student at IGc-USP - Brazil<br>Linux User #89721 - carlos dot grohmann at gmail dot com<br>+-----------------------------------------------------------+<br>_________________<br>"Good morning, doctors. I have taken the liberty of removing Windows<br>95 from my hard drive."<br>--The winning entry
in a "What were HAL's first words" contest judged<br>by 2001: A SPACE ODYSSEY creator Arthur C. Clarke<br><br><br><br>------------------------------<br><br>Message: 4<br>Date: Wed, 14 Mar 2007 17:13:41 -0500<br>From: William Kyngesburye <woklist@kyngchaos.com><br>Subject: [GRASS-user] New Mac OS X application build option<br>To: grass-dev@grass.itc.it, grassuser@grass.itc.it<br>Message-ID: <F45F4081-5B01-4EDA-B03D-9B7607E62E05@kyngchaos.com><br>Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed<br><br>Finally got the Mac OS X build option into CVS, with a little <br>configure/makefile help from Glynn.<br><br>To build GRASS as a Mac OS X application (exactly like my binaries, <br>if anyone has used those), add these options to your configure command:<br><br>--prefix=/Applications --enable-macosx-app<br><br>Since the default prefix is /usr/local and it's nearly impossible to <br>have multiple conditional default prefixes in configure, you should <br>set
the prefix as above.<br><br>It's tested with OSX 10.4 and the latest Xcode. It should work on <br>10.3, but it would be good to have verification of this if anyone <br>cares to try it.<br><br>Enjoy!<br><br>-----<br>William Kyngesburye <kyngchaos@kyngchaos.com><br>http://www.kyngchaos.com/<br><br>[Trillian] What are you supposed to do WITH a maniacally depressed <br>robot?<br><br>[Marvin] You think you have problems? What are you supposed to do <br>if you ARE a maniacally depressed robot? No, don't try and answer, <br>I'm 50,000 times more intelligent than you and even I don't know the <br>answer...<br><br>- HitchHiker's Guide to the Galaxy<br><br><br><br><br>------------------------------<br><br>Message: 5<br>Date: Wed, 14 Mar 2007 16:52:29 -0600<br>From: Trevor Wiens <twiens@interbaun.com><br>Subject: Re: [GRASS-user] linear referencing system - has anyone used<br> it?<br>To: "Lindsay Mico" <lindsaymico@hotmail.com><br>Cc: grassuser@grass.itc.it<br>Message-ID:
<20070314165229.57dd6f77@localhost.localdomain><br>Content-Type: text/plain; charset=US-ASCII<br><br>On Wed, 14 Mar 2007 12:37:28 -0800<br>Lindsay Mico wrote:<br><br>> I posted a question a few weeks ago about the linear referencing system. <br>> Has anyone actually used it to make new maps from field data? Unfortunately <br>> the developer of this function (Radim Blazek) no longer works on Grass. <br>> Below is a copy of my original question.<br>> <br>> Thanks and cheers.<br>> <br>> <br>> Fellow GRASS users,<br>> <br>> I would like to build a new point data layer from a large database of stream<br>> surveys which have 2 pieces of spatial info:<br>> <br>> 1) an LLID number for that stream<br>> 2) distance from the start of that stream<br><br>I've only used v.lrs.segment with single line segments, not networks<br>of lines. For this I passed this type of information formated as:<br><br>P stoptext catnum offset<br><br>in a
text file and piped it to the command.<br><br>> <br>> Based on what I have seen, I would use the linear referencing system<br>> modules. I am not sure if I need to build a new reference layer as I have a<br>> stream layer with the LLID info already in it. Additionally, I could not<br>> find an example of how v.lrs.segment works in practice. I have attempted to<br>> summarize things as I understand it to help make it easier to answer my<br>> questions. As I understand it the input parameters for v.lrs.segment would<br>> be as follows:<br>> <br>> 1) input= the stream layer with the associated LLID info<br>> 2) output = the name of the output layer<br>> 3) llayer = whether it is a point or line (is it 1 for line and 0 for<br>> point?)<br><br>Please refer to the GRASS vector intro for details on layers within<br>vector files. Essentially, unless you are messing with this "feature"<br>it will always be 1.<br><br>> 4) rsdriver = I
don't know what this means<br><br>dbf, pgsql, sqlite, etc<br><br>> 5) rsdatabase = the location of the file with the LLID # and distance<br><br>name of database, for example name of sql database. <br><br>> 6) rstable = the name of the file which has the LLID number and distance?<br><br>table name<br><br>> will it automatically add in the other data in the database? Or do I do<br>> that later using a spreadsheet program on the .dbf<br>> <br>> As I am still learning how to do this, I expect I will have more questions<br>> in the future. Hopefully this will be of use to others as well. Many<br>> thanks in advance. Cheers.<br>> <br><br>It is useful to read through all the material in the tutorial if you<br>haven't already done so.<br><br>T<br>-- <br>Trevor Wiens <br>twiens@interbaun.com<br><br>The significant problems that we face cannot be solved at the same <br>level of thinking we were at when we created them. <br>(Albert
Einstein)<br><br><br><br>------------------------------<br><br>Message: 6<br>Date: Wed, 14 Mar 2007 17:20:04 -0700<br>From: Michael Barton <michael.barton@asu.edu><br>Subject: [GRASS-user] Re: [GRASS-dev] New Mac OS X application build<br> option<br>To: William Kyngesburye <kyngchaos@kyngchaos.com>,<br> <grass-dev@grass.itc.it>, <grassuser@grass.itc.it><br>Message-ID: <C21DDF44.20497%michael.barton@asu.edu><br>Content-Type: text/plain; charset="US-ASCII"<br><br>Cheers to you and Glynn!<br><br>Michael<br><br><br>On 3/14/07 3:13 PM, "William Kyngesburye" <woklist@kyngchaos.com> wrote:<br><br>> Finally got the Mac OS X build option into CVS, with a little<br>> configure/makefile help from Glynn.<br>> <br>> To build GRASS as a Mac OS X application (exactly like my binaries,<br>> if anyone has used those), add these options to your configure command:<br>> <br>> --prefix=/Applications --enable-macosx-app<br>> <br>> Since the default prefix is
/usr/local and it's nearly impossible to<br>> have multiple conditional default prefixes in configure, you should<br>> set the prefix as above.<br>> <br>> It's tested with OSX 10.4 and the latest Xcode. It should work on<br>> 10.3, but it would be good to have verification of this if anyone<br>> cares to try it.<br>> <br>> Enjoy!<br>> <br>> -----<br>> William Kyngesburye <kyngchaos@kyngchaos.com><br>> http://www.kyngchaos.com/<br>> <br>> [Trillian] What are you supposed to do WITH a maniacally depressed<br>> robot?<br>> <br>> [Marvin] You think you have problems? What are you supposed to do<br>> if you ARE a maniacally depressed robot? No, don't try and answer,<br>> I'm 50,000 times more intelligent than you and even I don't know the<br>> answer...<br>> <br>> - HitchHiker's Guide to the Galaxy<br>> <br>> <br>> <br><br>__________________________________________<br>Michael Barton, Professor of
Anthropology<br>School of Human Evolution & Social Change<br>Center for Social Dynamics & Complexity<br>Arizona State University<br><br>phone: 480-965-6213<br>fax: 480-965-7671<br>www: http://www.public.asu.edu/~cmbarton<br><br><br><br><br>------------------------------<br><br>Message: 7<br>Date: Thu, 15 Mar 2007 14:09:48 +1300<br>From: Hamish <hamish_nospam@yahoo.com><br>Subject: Re: [GRASS-user] r.in.srtm help, again<br>To: antonio rodriguez <antonio.raju@gmail.com><br>Cc: grassuser@grass.itc.it<br>Message-ID: <20070315140948.271056b2.hamish_nospam@yahoo.com><br>Content-Type: text/plain; charset=ISO-8859-1<br><br>antonio rodriguez wrote:<br>> >> I have some bathymetric data from GEBCO which are in .grd format<br>> >> (GMT) so I've tried:<br>> >><br>> >> r.in.bin -h in=data.grd out=bati<br>> >><br>> >> and I get:<br>> >><br>> >> ERROR: North must be north of south<br>>
>><br>> >> The coordinates of the data are 38n/34n 9w/2w<br>> >><br>> >> I've tried too:<br>> >><br>> >> r.in.bin input=/home/toni/tmp/38n34n9w2w/38n34n9w2w.grd output=bati<br>> ><br>> >> north=38 south=34 east=-2 west=-9<br>> >><br>> >> Using rows=4 cols=11<br>HB:<br>> > ^^^^<br>> ><br>AR:<br>> >> ATENCIÓN: Bytes do not match File size<br>> >> ATENCIÓN: File Size 319216 ... Total Bytes 44<br>> >> ATENCIÓN: Try bytes=7254 or adjusting input parameters<br>> >><br>> >> So I tried with bytes=7254 (bytes=7255, bytes=7256) but I never get<br>> >> the right number<br>> >><br>> >> Any idea?<br>HB:<br>> > set the correct rows= and cols= options. Right now it is guessing<br>> > the raster resolution is 1 pixel = 1 degree x 1 degree.<br>> ><br>> > note the bytes description; it will mostly
always be 1, 2, or 4:<br>> > bytes Number of bytes per cell (1, 2, 4)<br>AR:<br>> I've made first:<br>> <br>> grdinfo 38n34n9w2w.grd<br>> <br>> 38n34n9w2w.grd: Title: GEBCO One Minute Grid<br>> 38n34n9w2w.grd: Command: 1.02<br>> 38n34n9w2w.grd: Remark:<br>> 38n34n9w2w.grd: Normal node registration used<br>> 38n34n9w2w.grd: grdfile format: cs (# 8)<br>> 38n34n9w2w.grd: x_min: -9 x_max: -2 x_inc: 0.0166667 name: user_x_unit<br>> <br>> nx: 421<br>> 38n34n9w2w.grd: y_min: 34 y_max: 38 y_inc: 0.0166667 name: user_y_unit<br>> <br>> ny: 241<br>> 38n34n9w2w.grd: z_min: -4060 z_max: 3110 name: user_z_unit<br>> 38n34n9w2w.grd: scale_factor: 1 add_offset: 0<br>> <br>> So from the nx and ny values above, in GRASS I've tried:<br>> <br>> r.in.bin input=/home/toni/tmp/38n34n9w2w/38n34n9w2w.grd output=bati <br>> north=38 south=34 east=-2 west=-9 rows=241 cols=421<br>> <br>> ATENCIÓN: Bytes do not match File
size<br>> ATENCIÓN: File Size 203536 ... Total Bytes 101461<br>> ATENCIÓN: Try bytes=2 or adjusting input parameters<br>> <br>> So, again:<br>> <br>> r.in.bin input=/home/toni/tmp/38n34n9w2w/38n34n9w2w.grd output=bati <br>> north=38 south=34 east=-2 west=-9 rows=241 cols=421 bytes=2<br>> ATENCIÓN: Bytes do not match File size<br>> ATENCIÓN: File Size 203536 ... Total Bytes 202922<br>> ATENCIÓN: Try bytes=2 or adjusting input parameters<br>> <br>> I tried with bytes=1 and bytes=4 but the same problem. The combination<br>> of rows, cols and bytes never match the file size: 203536<br><br><br>241 * 421 * 2 = 202922. Your file has 614 too many bytes. Header info?<br><br><br>I have the GEBCO bathy loaded into a lat/lon location here (sort of),<br>which I did back in Nov 2005.<br><br>Looking through the history I used this method-<br><br>Note the .jpg I used does not contain absolute depths.<br>The .jpg I have is 21601x10801 (1' +1),
6190902 bytes, greyscale.<br>gdalinfo:<br>Band 1 Block=21601x1 Type=Byte, ColorInterp=Gray<br><br><br>In a simple XY location:<br><br>r.in.gdal in=gebco_bathy.21601x10801.jpg out=gebco_bathy<br>r.region gebco_bathy n=90 s=-90 e=180 w=-180<br>g.region rast=gebco_bathy<br>r.out.mat in=gebco_bathy out=/tmp/grass/gebco_bathy.mat<br><br><br>In a Lat/Lon location:<br><br>r.in.mat /tmp/grass/gebco_bathy.mat<br>r.colors gebco_bathy col=grey<br><br><br>I may have done some adjustment in Matlab, it is too long ago to<br>remember. Probably I just used r.out.mat and r.in.mat to load the data<br>into a lat/lon location without "lat>90" type errors. The final z-scale<br>is 0-255, so that isn't much good for quantitative analysis. At minimum<br>it needs scaling. Maybe better r.region details to cover the (60*360)+1<br>too?<br><br><br><http: www.ngdc.noaa.gov="" mgg="" gebco="" grid="" 1mingrid.html=""><br>Looking at the "free download" website I give up in a sea of
online<br>registrations and "buy the full CD here". :-/<br><br><br>As an alternative, the etopo2 dataset is pretty nice and includes the 2'<br>Smith & Sandwell satellite altimetry ocean bathymetry. (See the article in<br>GRASS Newsletter vol. 1)<br><br><br>Hamish<br><br><br><br>------------------------------<br><br>Message: 8<br>Date: Thu, 15 Mar 2007 14:17:52 +1300<br>From: Hamish <hamish_nospam@yahoo.com><br>Subject: Re: [GRASS-user] ascii to dem<br>To: antonio rodriguez <antonio.raju@gmail.com><br>Cc: grassuser@grass.itc.it<br>Message-ID: <20070315141752.155f6eaf.hamish_nospam@yahoo.com><br>Content-Type: text/plain; charset=US-ASCII<br><br>antonio rodriguez wrote:<br>> I have imported into GRASS an ascii file (bathymetry) like this:<br>> <br>> r.in.ascii in=/home/toni/tmp/38n34n9w2w/baty2.xyz out=bati<br>> <br>> north: 38<br>> south: 34<br>> east: -2<br>> west: -9<br>> rows: 241<br>> cols: 421<br>> -9
38 -137<br>> -8.98333 38 -127<br>> -8.96667 38 -119<br>> -8.95 38 -112<br>> -8.93333 38 -101<br>> -8.91667 38 -81<br>> -8.9 38 -63<br>> -8.88333 38 -45<br>> -8.86667 38 1<br>> -8.85 38 8<br>> <br>> How do I transform it into a 'typical' dem map. It's to say a <br>> continous-aspect dem map not a dotted-aspect one?<br><br><br>That looks like x,y,z data, not a 2D ASCII array. r.in.ascii wants a 2D<br>array of z values, x,y are calculated from header. (see the example in<br>the help page)<br><br><br>Use r.in.xyz to import your data after crafting g.region settings by hand.<br><br><br>Hamish<br><br><br><br>------------------------------<br><br>Message: 9<br>Date: Thu, 15 Mar 2007 09:23:51 +0100<br>From: "Jose Gomez-Dans" <jgomezdans@gmail.com><br>Subject: [GRASS-user] Datum transformations<br>To:
grassuser@grass.itc.it<br>Message-ID:<br> <91d218430703150123t3ce96faar5feed36e3070aaed@mail.gmail.com><br>Content-Type: text/plain; charset=ISO-8859-1; format=flowed<br><br>Hi!<br>This is a GDAL-related question, but since I am also using GRASS, here<br>it goes. I have a number of GeoTIFF images in UTM30N/WGS-84 format. I<br>want to conver the datum to European 1950 and viceversa (in EPSG<br>parlance, this is a transformation from 32630 to 23030, if memory<br>serves). This is easily accomplished with gdalwarp, but I am unable to<br>specify the transformation parameters for my geographic area. For<br>example, if I define a region in GRASS from EPSG codes, I am asked for<br>the EPSG code, as well as for which datum transformation I want to<br>use. I believe this can be set in the -towgs84 paramter in GDAL, but I<br>am unsure on what numbers to use for Southern Spain (in GRASS, I think<br>it's either datum transform option 4 or 5 for a location defined as<br>EPSG
23030). Can anyone point me to the file where these parameters<br>are stored, or some other relevant info?<br><br>Many thanks!<br>jose<br><br><br><br>------------------------------<br><br>_______________________________________________<br>grassuser mailing list<br>grassuser@grass.itc.it<br>http://grass.itc.it/mailman/listinfo/grassuser<br><br><br>End of grassuser Digest, Vol 11, Issue
22<br>*****************************************<br></jgomezdans@gmail.com></antonio.raju@gmail.com></hamish_nospam@yahoo.com></http:></antonio.raju@gmail.com></hamish_nospam@yahoo.com></kyngchaos@kyngchaos.com></woklist@kyngchaos.com></C21DDF44.20497%michael.barton@asu.edu></grassuser@grass.itc.it></grass-dev@grass.itc.it></kyngchaos@kyngchaos.com></michael.barton@asu.edu></lindsaymico@hotmail.com></twiens@interbaun.com></kyngchaos@kyngchaos.com></F45F4081-5B01-4EDA-B03D-9B7607E62E05@kyngchaos.com></woklist@kyngchaos.com></tutey@o2.pl></bd07447b0703141506s70eee005x7cabed633b608351@mail.gmail.com></grassuser@grass.itc.it></carlos.grohmann@gmail.com></grassuser@grass.itc.it></carlos.grohmann@gmail.com></tutey@o2.pl></BAY121-F4D714BD180BC006550BE5A3730@phx.gbl></lindsaymico@hotmail.com></blockquote><br><BR><BR><DIV><STRONG>Pawan Joshi</STRONG> </DIV> <DIV> </DIV> <DIV><BR><BR> </DIV><p> 
<hr size=1>Ahhh...imagining that irresistible "new car" smell?<br> Check out
<a href="http://us.rd.yahoo.com/evt=48245/*http://autos.yahoo.com/new_cars.html;_ylc=X3oDMTE1YW1jcXJ2BF9TAzk3MTA3MDc2BHNlYwNtYWlsdGFncwRzbGsDbmV3LWNhcnM-">new cars at Yahoo! Autos.</a>