[GRASSLIST:2941] Re: s.to.rast help

[Andrea Aime]

s.out.rast should output the value contained in the chosen field
(field parameter in s.out.rast), but the image you have posted makes
no sense... I can see the white squares but the background seems some
kind
of interpolated data, and s.out.rast cannot output this, the s.out.rast
should look like a white background and some coloured spots where the
points reside... have you obtained this image using d.rast -o, that is,
by overlaying an interpolated raster and the output of s.out.rast? If
this is true, the squares cannot contain NULL data since they should
be transparent on the image... There is something that makes no sense
here...
Moreover, what version of GRASS are you using?
Best regards
Andrea Aime

Kevin Slover wrote:
> 
> Andrea, and all,
>         I apologize for the size of the last email.  I did not realize the size
> until it went out, should be more aware of what I am sending...
>         The command that I used was s.to.rast input=test.sites output=test.rast
> size=3.  Not sure how much of the other discussion you have heard...the
> sites are ~500m apart, and my cell size I set at 100m.  Should cover the
> entire area...
> 
> Andrea Aime wrote:
> >
> > Hi Kevin,
> > sorry for posting you a complaint rather than an help, but
> > try to consider that some people on the list have only
> > dial-up access on a pay per use line, and it's not funny
> > to stay 40 minutes on the telephone just to see your postings...
> > please, next time try to use ASCII art like Eric, or at
> > least compress them in JPEG format... a 50K email is annoying,
> > a 3 MB mail like this one is definitely unbearable... if I
> > could not delete this mail from my web mail client I would have
> > to wait at least 40 minutes to download it!!!
> > I hope you will understand our problems...
> >
> > More related to your problem: can you post the exact command
> > sequenced performed to get that raster file?
> > Maybe it's a bug, maybe we just don't
> > see something that may become obvious taking a look at the
> > commands used to build that file...
> >
> > Best regards
> > Andrea Aime
> >
> > Kevin Slover wrote:
> > >
> > > Eric,
> > > thanks for the response.  I guess it is difficult to explain...You
> > > answer has given me a bit more insight on the s.to.rast command.
> > > However, with that explanation, it makes it that much more puzzling.
> > > Taking your example below, the 0 representing my data point, and the X's
> > > representing the "buffered" cells...my data point "cell" is given a NULL
> > > value, and the other "buffered" cells are given a value.  I will attach
> > > a tif image, which might give more of an explanation of the problem.  I
> > > am sure the outputted white areas on the raster are null, as I have done
> > > both r.what.rast and r.out.xyz, and get NULL values.  I am sure there is
> > > some simple solution to this problem, that I am overlooking some step
> > > somewhere, but it is evading me right now.
> > > And, as I said in the last email, r.fillnulls doesn't recognize the NULL
> > > values, yet they are clearly there...any ideas??
> > >
> > > > I'm sorry, but it's not clear what the problem is.  The s.to.rast module
> > > > creates a cell value for each site it falls within (given the current
> > > > region settings).  If you ask for additional cells, the cells grow out
> > > > in every direction by the number given.  So, "buffered" by three cells
> > > > gives you something the following (for a given site):
> > > >
> > > >        X X X X X X X
> > > >        X X X X X X X
> > > >        X X X X X X X
> > > >        X X X O X X X
> > > >        X X X X X X X
> > > >        X X X X X X X
> > > >        X X X X X X X
> > > >
> > > > So, if your sites are 500m apart, with 100m cell size, the edges of the
> > > > "buffered" cells will probably colide (and you should get warnings about
> > > > this).
> > > >
> > > > As far as nulls go, are you sure there any remaining?  At the beginning
> > > > of the run, the program writes out all cells as NULL.  It then writes
> > > > the corresponding sites data cells (as buffered), possibly clobbering
> > > > previously written values (aforementioned warning).
> > > >
> > > > --
> > > > Eric G. Miller <egm2 at jps.net>
> > >
> > > --
> > >         LTJG Kevin Slover,NOAA   GIS
> > > Specialist/Meteorologist/Oceanographer
> > >               Tropical Prediction Center/National Hurricane Center
> > >                     11691 SW 17th Street Miami FL 33165
> > >                  Work: (305) 229-4456 Fax : (305) 553-1264
> > >
> > >   ------------------------------------------------------------------------
> > >                    Name: example1.tif
> > >    example1.tif    Type: TIFF Image (image/tiff)
> > >                Encoding: base64
> > >
> > >                    Name: example2.tif
> > >    example2.tif    Type: TIFF Image (image/tiff)
> > >                Encoding: base64
> 
> --
>         LTJG Kevin Slover,NOAA   GIS
> Specialist/Meteorologist/Oceanographer
>               Tropical Prediction Center/National Hurricane Center
>                     11691 SW 17th Street Miami FL 33165
>                  Work: (305) 229-4456 Fax : (305) 553-1264