Posted 14 October 2010 - 07:27 AM

In order to convert point data into a raster you need certain software. Since you are working with viewsheds, I assume you have Arc's 3D Analyst and Spatial Analyst. There's a tool called "Topo to Raster" that comes with one of them which should do what you want. (Since I don't have 3D or Spaital Analyst, I use MapInfo with the Discover3D Module for such interpolations, or you could use Surfer or other software packages.)

Once you have your new raster, I'd mosaick it together with the SRTM data. In the mosaick tool of ArcView you can define what resolution the final combined raster should have and which of the inital rasters takes precedence over the other where they overlap. (I think you can skip your step b.) You will end up with a new raster saved under a new file name, leaving your two initial rasters unchanged.

SouthernCross

Posted 14 October 2010 - 10:06 AM

SouthernCross

Contributor

Validated Member

47 posts

Gender:Male

Location:City of Kawartha Lakes, Ontario

Canada

In order to convert point data into a raster you need certain software. Since you are working with viewsheds, I assume you have Arc's 3D Analyst and Spatial Analyst. There's a tool called "Topo to Raster" that comes with one of them which should do what you want.Hope this helps.

Actually Topo to Raster has some very limiting features, namely pixel sizes. It can only create raster datasets that are 5000 pixels x 5000 pixels. Also, when selecting the "sink" option, the function may fail with over 8000 sinks present (I have been successful at times though). Of course, if you are trying to convert a small area then you should be good to go. Also, I would recommend running a nearest neighbour function on the created grid to smooth it out a bit.

If you have 3d analyst another way to do this is to create a TIN of your points (use the mass points function). Then convert the TIN to raster. I find I have much more control this way and it handles larger areas a bit better. This is how I do a lot of bathymetry stuff. If you want a raster dataset with a high cell resolution, then this is probably the better way to go.

Ruben

Posted 16 October 2010 - 04:35 PM

Ruben

Newbie

Validated Member

4 posts

Netherlands

Thanks for your replies!

I created two maps based on your instructions - one based on a TIN and one on the topo-to-raster - and carried out a simple viewshed from one point. Two maps, because I wanted to see the difference in outcome between the TIN and the topo method.The resulting viewshed shows that something is wrong with both maps. A clip of the output is attached to this post, and you'll immediately notice the odd stripes and triangles. That's problem 1.

There's more. The photo linked above shows the real-world situation (I didn't have any without a prism blocking view ). The blue dot on the aforementioned screenshot is the place wherefrom the viewshed was executed. It lies just behind the place where the photo was taken and is situated on top of a hill. The red dot more or less corresponds with the lower hilltop at the end of the dirt road leading up, middle-left in the photo. The blue line corresponds with the hills in the background. Between the red dot and the blue line lies a valley, which is not visible from the blue dot, but, as you can see, the red dot and the blue line should be visible. Problem is, the blue line is not in the generated viewshed. There are no sudden terrain bumps or things like that block view in my DEM as far as I can see.

To summarize:(1) odd stripes and triangles in the viewshed(2) the viewshed is partly incorrect

Any ideas? I think it has something to do with the mosaicing process, because viewsheds using the original two maps come out fine.

Posted 18 October 2010 - 01:14 AM

On the first glance, your screenshot with the triangles and steps looks very weird indeed, but on second thoughts it makes sense to me: The problem is that there are "pixels" of a certain rather large size with sharp boundaries. Basically your area is modelled by a bunch of square prisms of different height standing one next to the other. Now imagine yourself standing on your viewpoint, looking at this stepped countryside. You'll see the first step just fine, but then there's a drop and the second step is a bit lower, so the edge of the first step will cover some of the second step, so that won't be visible. (I hope I can make myself clear here!)

So in essence it's not something wrong with your data but data of the wrong resolution for your purpose. Even if you resampled your data at a finer resolution, you'd still have the same steps, now just made up of several pixels instead of bits of one pixel. You would have to interpolate while resampling, which would suggest much better data quality while in fact smoothing out details like small streambeds, so maybe that's not an option. Or you'd need to extend the area where you took GPS measurements by hand.

On second thoughts: You said the viewsheds of your inital two rasters are fine. Maybe you can avoid your problems altogether by switching the processing steps: first calcualte viewsheds separately, then take your detailed viewshed and replace the corresponding parts of the SRTM viewshed.

Ruben

Posted 18 October 2010 - 03:17 AM

I have to agree about Topo to Raster....TIN would better option. Do you have any stream data to go with the points?

In addition to mosacing, you could also try the Con function (if you have the Spatial Analyst extension).

But regardless of method, one likely issue you are most likely to encounter is an elevation difference between the SRTM and the high-res 5m sampling.

You could end up with serious walls or drops at your intersecting boundary.

No other data, just the points. Is there a way to smooth the transition between both rasters?

On the first glance, your screenshot with the triangles and steps looks very weird indeed, but on second thoughts it makes sense to me: The problem is that there are "pixels" of a certain rather large size with sharp boundaries. Basically your area is modelled by a bunch of square prisms of different height standing one next to the other. Now imagine yourself standing on your viewpoint, looking at this stepped countryside. You'll see the first step just fine, but then there's a drop and the second step is a bit lower, so the edge of the first step will cover some of the second step, so that won't be visible. (I hope I can make myself clear here!)

That's perfectly understandable, and I can agree to a certain extent. As mentioned before, SRTM data is used as the main data source. Consequently, those cells are approximately 86 x 86 m, indeed very large when compared to the much finer manually acquired data. The screenshot shows the DEM after the merging of both files, so the actual cell size here is already decreased. No interpolation has taken place, hence the 'terracing'.

So in essence it's not something wrong with your data but data of the wrong resolution for your purpose. Even if you resampled your data at a finer resolution, you'd still have the same steps, now just made up of several pixels instead of bits of one pixel.

That's the current situation.

You would have to interpolate while resampling, which would suggest much better data quality while in fact smoothing out details like small streambeds, so maybe that's not an option. Or you'd need to extend the area where you took GPS measurements by hand.

How would I go about interpolation? I don't know which method is appropriate in this case.

On second thoughts: You said the viewsheds of your inital two rasters are fine. Maybe you can avoid your problems altogether by switching the processing steps: first calcualte viewsheds separately, then take your detailed viewshed and replace the corresponding parts of the SRTM viewshed.

There's is a simple reason why I can't do that: the viewshed has to be computed using both rasters combined. The valley mentioned in my previous post should not be visible, but is visible when a viewshed is calculated using only SRTM data (not enough detail). I can't simply use the more detailed DEM on its own, because the valley falls outside its border. What is does contain, is more precise height values of the second, lower hilltop, which stands right between the valley and the observer. This information is missing from the SRTM data. A merge of both rasters would, in theory, contain all data needed to carry out the viewshed.

Another thing, the border-problem doesn't explain why the western hills (blue line) isn't visible in the viewshed. There are no sudden bumps blocking view as far as I can see.

I hope I'm not becoming too much of a bother I just want a viewshed that shows that the western hills and the lower hilltop are visible, while the valley is not, and the data available to me, while far from perfect, should be detailed enough to provide just that.

Ruben

Posted 18 October 2010 - 10:28 AM

Could you explain your exact method for calculating these grids. What are the exact selections you chose? Did you smooth out the grids you created using a nearest neighbour function before mosaicing?

In general, it is bad practice to mosaic two grids with markedly different resolutions. However, I do understand the practical need to do so at times.

Sure.

Raster 1: SRTM data acquired from http://srtm.csi.cgiar.org/. Mosaiced two rasters together, because I'm mostly interested in a large area. I then simply clipped a rectangle containing the area of interest for this viewshed.

Raster 2: Point data, as described earlier. This was converted to a TIN per your instructions, 3d Analyst / Create TIN / Create TIN from features - point file selected / correct height source selected / triangulate as mass points. The TIN was then converted to a raster, using 3d Analyst / Convert / TIN to raster - attribute 'elevation', cell size '5'.

Do you refer to 'resample using nearest neighbour' when speaking about 'nearest neighbour'? If so, I tried that on the individual rasters before mosaicing / mosaic/ viewshed. I also tried to resample the final map using nearest neighbour before calculating the viewshed, yielding the same result. If not, what method/settings do you suggest?

EditI've messed around a bit with both rasters, and I'm sure that raster 1 is to blame. Attached file 1 shows a hillshade of said raster using default settings. Notice how the same striping pattern appears, this time even more obvious. This happens only if I resample the original SRTM file (or a clip) to a 5m resolution using nearest neighbour. Projecting, mosaicing, clipping and so on don't cause problems. It does not happen if I choose bilinear interpolation when resampling, but the hillshade turns grainy and a glitch becomes apparent in the NE (see second screenshot). Any idea why, and am I losing a lot of detail using this method?

Starting from the original srtm_41_05.asc, srtm_41_06.asc, srtm_42_05.asc and srtm_42_06.asc:- mosaic- reclassify <0 + nodata to 0 (might not be good practise, but it's quick and good enough for the target area)- clip raster using a polygon shape file- project raster -> UTM 35N- resample

Attached Thumbnails

SouthernCross

Posted 19 October 2010 - 07:13 AM

SouthernCross

Contributor

Validated Member

47 posts

Gender:Male

Location:City of Kawartha Lakes, Ontario

Canada

Something I noticed with your SRTM data is that it is very reminiscient of a dataset that has been been created with too fine of a cell size. I'm assuming that the cell size of '5' is not what it is natively. If the number goes too small then you can get a lattice type of appearance in the hillshade grid. I would try increasing the number by increments of 2 until you get a more congruent dataset.

Unfortunately, there is only so low you can go on a dataset that has poor cell resolution to start with. You can get away with it in the DEM, but when creating a hillshade, it will show.