[GRASS-user] DEM with bathymetric contour lines
brunclik at atlas.cz
Tue Jun 2 05:45:23 PDT 2015
the problem for me really was the areas not filled by any contours - it
is mentioned in the manual that it is not good.
I stopped the processing and first tried again on much smaller
sub-region - on region about 1000x1000 pixels it was still as slow as
showing 0% progress for several minutes, then tried with ~500x500 and it
took few minutes and worked well. Then I returned to the whole region,
but created mask using buffer 65m (this is more than maximal distance
between two contours anywhere within the water areas) around the
contours and it worked like a charm - the whole region of 5676x4142
pixels with 1m resolution minus the mask was processed with good
results. I do not know exact time, because I left the computer for two
hours, but according to the progress before I left it took minutes, not
Irantzu, if you have places of size in hundreds of region pixels or more
not covered by contours, try to use the mask as I did and tell us if it
solved your problem. If these places are not inland, but just some flat
parts of the water bottom, you can still fill the resulting holes in the
dmt by other means later, like r.fillnulls or other interpolation methods.
What I did: looked at the data and found that the contours are max about
32m apart. Used double of that distance (65m) to be on the safe side.
r.buffer input="contours_rast" output="contours_buff" distances=65
# to get the min and max of the contours_buff (min was 1, max was 2)
r.mask raster=contours_buff cats="1 thru 2"
r.surf.contour --overwrite input=contours_rast output=dmt_rast
Dne 2.6.2015 v 11:58 Markus Neteler napsal(a):
> On Tue, Jun 2, 2015 at 10:18 AM, Tomáš Brunclík <brunclik at atlas.cz> wrote:
>> Hello all,
>> after about 10 hours of processing (the computer got to sleep state over
>> night) still progress 0%.
> You may file an enhancement ticket - likely r.surf.contour has never
> been optimized.
>> Is it normal on such region size and core i5 PC?
> Well, it will only use 1 CPU unless being parallelized. But often a
> code optimization is more efficient (as done for many modules in GRASS
> GIS 7, see https://trac.osgeo.org/grass/wiki/Grass7/NewFeatures).
> Maybe there is potential in r.surf.contour as well.
> Just one other hint below:
>> Dne 1.6.2015 v 11:44 Tomáš Brunclík napsal(a):
>> Hi Irantzu,
>> I am just trying again with this dataset:
>> For the record, the commands I used:
>> #First created new location using the data as source of its projection
>> settings and imported the file (from startup GUI), then:
>> g.region vector=ES2003_1m_mb_contour at PERMANENT
>> g.region res=1
> better use
> g.region res=1 -a
> in order to avoid "odd" pixel resolution:
>> g.region -p
>> nsres: 0.99998578
>> ewres: 1.00006542
> ... this will then become precisely 1.0.
> I'll now try myself the interpolation.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the grass-user