Viewshed inconsistencies

[Anonymous User]

Original User: kkvh5369

Hi all,
I am teaching a GIS module.  My students had to calculate a viewshed based on a single point and a DEM - all had the same datasets (downloaded from the same source) and the same license / version of ArcGIS (9.3, SP1 on an Info license - with the spatial analyst extension checked).  A few of them ended up with a totally different result to the majority (screenshots below), despite using the same data and running the tool in the same way as everyone else.  We tried re-downloading the data, in case the data was corrupt, but still the same students ended up with a different viewshed to the majority.  They have tried it on different machines (we are working on networked computers in a university).  I can't think why this would happen, and can't replicate the error on my own machine or fix it on theirs!  Any clues very gratefully received...
Thanks,
Kate.
The attribute table of the observation point:
[ATTACH=CONFIG]12388[/ATTACH]

The "correct" viewshed (i.e. the viewshed that the vast majority of students, and I, got):
[ATTACH=CONFIG]12389[/ATTACH]

The "incorrect" viewshed (i.e. for a few students, approx. 5 out of 65):
[ATTACH=CONFIG]12387[/ATTACH]

[DanPatterson_Retired]

Did they all use the same cell size and analysis extent?

[Anonymous User]

Original User: csny490

Try converting your input point(s) to raster 1st and use the raster format data as input to the viewshed tool. Like Dan said, make sure the cellsize, extent, AND snapraster are being entered consistently. Sometimes people accidently/unknowingly set default values for these envr variabales -which screws everythig up. Since these envr settig are stored in your profile, this sounds like what may be happening in your case.

But...

A similar issue: In v9.3.1 (not sure in v10.0), the Watershed tool would occasionally give incorrect results, even though the input vector point was clearly in the cell center. I only noticed this problem because it was part of a python script that looped through thousands of points. The problem was rare, and didn't seem to be cosistent, but quite annoying. To ensure a consistent outcome, I learned to always convert the point to a raster 1st, and use the raster as input. Doing so resulted in the correct outcome 100% of the time. Not sure what the issue is/was... Maybe the interal method ESRI uses for their snapraster setting - maybe a slight difference in decimal precision the snapraster alogrthm uses vs. raster cellsize percision - enough to throw the results off by 1 pixel?

[KateParks]

Hi,
Thanks for your suggestions - I will investigate and update after the next practical session.
Kate.

[Anonymous User]

Original User: kkvh5369

Got to the bottom of it!  The data was distributed in a zipfile; the students who were getting the error weren't extracting the data before calculating the viewshed - they were simply opening the zipfile and copying the contents into a working directory.

Thanks for your help,
Kate.