Hanlie Pretorius wrote: > 2010/6/5, Hamish <hamis...@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@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/grass-user > _______________________________________________ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
