Hello,
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
hours.
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.
The commands:
r.buffer input="contours_rast" output="contours_buff" distances=65
units="meters"
# to get the min and max of the contours_buff (min was 1, max was 2)
r.info contours_buff
r.mask raster=contours_buff cats="1 thru 2"
r.surf.contour --overwrite input=contours_rast output=dmt_rast
Regards,
Tomas B.
Dne 2.6.2015 v 11:58 Markus Neteler napsal(a):
On Tue, Jun 2, 2015 at 10:18 AM, Tomáš Brunclík <brunc...@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:
https://dl.dropboxusercontent.com/u/24062833/ES2003_1m_mb_contour.zip
...
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@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.
Markus
_______________________________________________
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
