[GRASS-user] DEM with bathymetric contour lines

[Tomáš Brunclík]

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 <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:
>> 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 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.
>
> Markus

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/grass-user/attachments/20150602/3010b3a8/attachment.html>