[GRASS-user] Re: Importing Dems with r.in.xyz

[Markus Metz]

Hanlie Pretorius wrote:
> 2010/6/5, Hamish <hamish_b at yahoo.com>:
>> Hanlie wrote:
>>> >> At this point, g.region reports 1146474 cells in the region, while I
>>> >> have 1146370 lines of coordinates in my file.
>> ...
>>> > So it looks like there are about 100 coordinates missing from the ASCII
>>> > ASCII file.
>>
>> 0.01% ..
>>
>>> Maybe "holes" in the data?
>>
>> perhaps this:  https://trac.osgeo.org/grass/ticket/123
>> ??
>
> I don't think it's this bug because this bug discards only one line of
> data. I don't get any data in because the number of coordinate pairs
> in the file is less than the number of cells in the defined region.

Weird. In 6.4, r.in.xyz does import a file where the number of
coordinate pairs is far less than the number of cells in the defined
region. (I just did a simple test with two input lines and a region
with 26.5 million cells, got clean import and correct result)

You can interpolate NULL cells and a the same time keep non NULL cell
values with r.fillnulls.

I would suggest to set the region to

north:      -49312.5
south:      -74587.5
west:       -3015862.5
east:       -2987512.5
nsres:      25
ewres:     25

have clean 25m resolution for both ns and ew in order to make life
easier. The 1cm difference in the last input lines you posted can not
possibly make a difference with 25m point spacing and is most probably
some floating point rounding error introduced by some preprocessing to
generate the ascii xyz input file.

HTH,

Markus M

>
>>
>>
>>> I was thinking perhaps importing the points as vectors, converting
>>> them to raster and then doing a nearest neighbour or IDW interpolation
>>> to fill the gaps. At least then I'll be able to see where the gaps are
>>> and limit the interpolated pixels using a mask?
>>
>> No need to do anything different to find the missing pixels. Inspecting
>> the output of r.univar with r.in.xyz's method=n maps can be very useful
>> for troubleshooting.
>>
>>
>> from the help page:
>>
>>    Gridded data
>>        If data is known to be on a regular grid  r.in.xyz  can
>>        reconstruct  the  map perfectly as long as some care is
>>        taken to set up  the  region  correctly  and  that  the
>>        data's  native map projection is used. A typical method
>>        would involve determining the grid resolution either by
>>        examining  the  data's  associated  documentation or by
>>        studying  the  text  file.  Next  scan  the  data  with
>>        r.in.xyz's  -s  (or  -g)  flag to find the input data's
>>        bounds. GRASS uses the  cell-center  raster  convention
>>        where  data points fall within the center of a cell, as
>>        opposed to the grid-node convention. Therefore you will
>>        need  to  grow  the  region  out  by half a cell in all
>>        directions beyond what the  scan  found  in  the  file.
>>        After  the  region  bounds  and resolution are set cor-
>>        rectly with g.region, run r.in.xyz using the  n  method
>>        and  verify that n=1 at all places.  r.univar can help.
>>        Once you are confident that the region exactly  matches
>>        the data proceed to run r.in.xyz using one of the mean,
>>        min, max, or median methods. With n=1  throughout,  the
>>        result should be identical regardless of which of those
>>        methods are used.
>>
>>
>> with the "n" map you might use r.mapcalc to extract the NULL cells
>> as some value, then r.out.xyz or r.to.vect on th extracts to highlight
>> where they are. Or maybe you get lucky with r.colors with "nv" set to
>> bright magenta on the original data.
>
> Thanks, I'll try this to find where the holes in the data are.
>
>>
>>
>>
>> Hamish
>>
>>
>>
>>
>>
> _______________________________________________
> grass-user mailing list
> grass-user at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-user
>