Stack Exchange Network

Stack Exchange network consists of 175 Q&A communities including Stack Overflow, the largest, most trusted online community for developers to learn, share their knowledge, and build their careers.

Visit Stack Exchange

Hot answers tagged

3

How about something like this: radius=5000 # Maximum distance X=200000 # X coordinate of lookout Y=500000 # Y coordinate of lookout r.import dem.tif output=elev g.region -a rast=elev r.viewshed input=elev output=vshed max_distance=$radius coordinates=${X},${Y} r.to.vect input=vshed output=vshed type=area This should leave you with a raster named "...


3

The logical approach is correct, but 60 Gb is a massive raster file: I would first asses if all that detail is really needed. A 0.3 raster over Hong Kong seems a little far, if the input data does not have that resolution. Keep also in mind that the contouring process by definition introduces a smoothing of the data. If reducing the detail is not an option ...


2

I have solved this problem numerous times. I have a Matlab solution posted here, and a Python solution is included in my (soon to be released) RivGraph package here. The function you'd be interested in is called "mask_to_centerline." It takes the approach of skeletonizing (or thinning) and finding the longest, shortest path between end-locations as the ...


2

Just to confirm again, it worked for me as well. Might worth double checking which version of GRASS you are using. I tried with GRASS 7.6.1 in Linux mint and Windows 10 with WGS 84 / UTM projection. v.buffer -s --overwrite input=Points@PERMANENT output=square_buffer distance=100


2

Worked for me. What operating system and which version of GRASS are you using? micha@TP480$ v.buffer -s ims_stations_s type=point out=ims_buffers dist=1000


2

Here are the replies by mankoff and mmetz from trac.osgeo: I think the issue is related to the region. There is a work-around for the bug: g.region raster=<raster> -a The r.slope.aspect documentation in the NOTES section implies that the region is adjusted to the raster. I do not find that to be the case. Specifically in the NC test data, I've ...


2

Got it! My mistake was in the new attribute field conversion. Must change v.db.addcolumn riodejaneiro2D col="altura integer" to v.db.addcolumn riodejaneiro2D col="altura double precision" Now I have | Map is 3D: Yes | | Number of dblinks: 1 ...


1

This answer is largely based on the comments by Micha, posted to the original question. These are reiterated here so that the question can be marked as answered. The problem seems to arise from computer rounding error that results in the lines being ever so slightly off the point. One work-around is creating a small buffer around the point and running v....


1

Yes, the WHERE conditions should not apply to your case, but unfortunately we cannot escape from this keyword - it is mandatory as far as I know. I usually set a dummy (meaningless) condition, such as "ID" > 0 or "ELEVATION" < 1000000 so that the conditions always return TRUE. [Example] - Natural Earth dataset Ir has a "scalerank" field which is ...


1

I think that the GRASS commands r.thin, and then r.to.vect ... type=line should do what you want. You have to prepare the scanned raster first by setting all the pixels that cover the river to a single value (it seems to be so from your image), and all the surrounding pixels must be NULL (r.null setnull=...) (Edit:) Here's the procedure I tried and the ...


Only top voted, non community-wiki answers of a minimum length are eligible