brainteaser viewshed wind turbines - the more you see the worse it gets...

Anonymous User · ‎08-02-2013

Original User: firefry82

working with arcgis 10.1 Sp1

Hi everybody,
I have a little brainteaser for you: I am trying to make a visibility analysis of wind turbines. But instead of the simple viewshed thing, I am trying to include stuff like partial visibility and multiple visibilities. The latter one is driving me insane and I hope some of you guys (or girls of course) maybe have an idea how to approach this.
I have zones around each single turbine, which indicate the level of visual distress in relation to the distance.
[ATTACH=CONFIG]26444[/ATTACH]
I can now merge them to a big viewshed which works fine.

To include the multiple visibilities I need to consider the folowing idea from "Paul et al. 2004"

[ATTACH=CONFIG]26442[/ATTACH]
Paul et al 2004 & ECOGIS
Even though this is for tension towers I think it is about the same for wind turbines. It says that the visibility increases when more when multiple turbines are visible. So he set up a factor which is 1 for the closest turbine, 1/2 for the second closest, 1/3 for the third closest and so on (1/i). Now how do I find out which turbine is closest to each cell from my raster? and then how do I get a hold of the zone-id?

This is the idea sketch:

[ATTACH=CONFIG]26447[/ATTACH]

What I tried so far:
1) converted viewsheds to polygones, made union analysis to try to intersect each one with the other to find overlapping areas. Then could go through each row and find the biggest zone-id which would be taken in account by the factor 1, the second biggest zone-id with 1/2 and so on. --> failed because union analysis can'T handle the data load

2) tried intersect the the polygon-viewsheds without the union, but then only a small part in which they ALL intersect is produced. I the searched for a intersect method that maybe finds and visualizes all the intersections from the overlaps...but I didn't find anything

3) tried to work it out with the raster calculator, but then I wouldn't know how to tell him that he should only take the zone-value when it is the closest to the cell...

I just can't get my head around it...

I am open for any ideas, phyton-scripts, ...whatever...

Anonymous User · ‎08-12-2013

Original User: csny490

"If something is hard you should just give up, since it probably wasn't worth doing it in the first place."

NOT!

Question: What if two towers were visible: One at 200m distance, and the other at 201m distance (shouldn't that distance rank variable be a bit more scaler?)

Okay - How about this (and BTW, this would go way faster if you can coarsen the cell size). Also, make sure the cells are all alligned by setting a snap raster. Also, be aware you might fill up your RAM depending on how many pixels are involved:

1. For each tower make a viewshed/euclidean distance raster so that the output raster name has the tower id in it "tower_12", and the raster values are the distances away from the tower.
2. Convert that raster to a point featureclass.
3. Using a search cursor, load all the point FCs into a Python dictionary. The dictionary key will be a tuple of the X,Y coordinate pair.

So maybe some thing like this (warning UNTESTED!):

pointDict = {} pointFcList = ["tower_1.shp","tower_2.shp","tower_3.shp"] for pointFc in pointfcList:    searchRows = arcpy.da.SearchCursor(pointFc, ["SHAPE@XY","DISTANCE"])    towerId = pointFc.split("_")[-1]    for searchRow in searchRows:       xyKey, distance = searchRow       if xyKey not in pointDict:          pointDict[xyKey] = [(distance, towerId)]       else:          pointDict[xyKey].append((distance, towerId)) for keyKey in pointDict:    pointDict[xyKey].sort()

So now (I think) you have everything you need to compute the score:

How many towers are visible at a given x,y coordinate? len(pointDict[xyKey])
What is the closest tower's distance to a given x,y coordinate? pointDict[xyKey][0][0]
What is the closest tower id to a given x,y coordinate? pointDict[xyKey][0][1]
How about the 2nd closest tower distance? Or the 3rd? pointDict[xyKey][1][0], pointDict[xyKey][2][0]
How about the 2nd closest tower id? Or the 3rd? pointDict[xyKey][1][1], pointDict[xyKey][2][1]

View solution in original post

Anonymous User · ‎08-04-2013

Original User: firefry82

okay here is a little update:
I managed to do the following
1) calculate all the intersects from each viewshed to viewshed 1, then 2 and so on.
this gives me a load of intersecting polygons for every viewshed.
2) with the help of the near-function I can now determine for each of these (intersection-)polygons how far away it is, which when brought to order gives me (theoretically) the nearest, second nearest , third nearest and so on object in relation to my first viewshed.
3) then (after conversion to raster) I can add them up by dividung the vakue of the (intersection-)raster by the number of its appearence

This works (theoretically) fine, but I have 155 viewsheds in my first set of data and if I do this calculation with every viewshed it will take a very, very long time. For an one second calculation about 7 hours. And the calculation will exceed one second by far.

How else can I approach this?

At first I just added the rasters which gave me the seemingly right outcome, but on a closer look it was skewed.

lets say the outer zone has the value of 1 while the inner (closest to the turbine) zone has the value of 6. Then if I just add up the zoned rasters six overlapping zone one's have the same value as the original zone 6. therefore I wanted to include the division

nb · ‎08-06-2013

okay, the last approach seemed to be a dead end, BUT what if I would calculate the order of distance for each cell?
like:
cell 1= turbine112, turbine 7, turbine 39 ...and so on...
then I could sum up the values like this :
cell1= ([value from turbine112] *1) + ([value from turbine7] /2) + ([value from turbine39] /3)

but how do I do this? the euclidean distance only shows how far it is to the closest turbine and doesn't give me any idea which turbine it is...
damn it this shouldn't be to hard, why can't I figure this out??!

Anonymous User · ‎08-06-2013

Original User: curtvprice

but how do I do this? the euclidean distance only shows how far it is to the closest turbine and doesn't give me any idea which turbine it is...

The euclidean allocation grid is used to provide that information. It can be generated with its own tool or using as an optional argument to the Euclidean distance tool.

Take a deep breath, I think you're making progress. 🙂

nb · ‎08-07-2013

Yes I know, I already tried it with euclidean allocation but it still only gives me the ID to the closest turbine. But I need the ID to the closest, the second closest, the thrid closest and so on. I don't see a way, how I could manipulate the tool to these specifications...

Anonymous User · ‎08-07-2013

Original User: csny490

But I need the ID to the closest, the second closest, the thrid closest and so on.

How about making a euclidean allocation grid for the 1st closest, then another one for the 2nd, 3rd, etc.. Then use the combine tool to basically union all the euclidean allocation grids?

Maybe it would just be easier to make a bunch of seperate viewshed rasters and then combine them together.... then cursor through the table and work out some sort of scoring system.

nb · ‎08-07-2013

first of all thank you two so such for your efforts! I'm really strugelling with this and desperatly need new ideas / input.

@ csny490

How about making a euclidean allocation grid for the 1st closest, then another one for the 2nd, 3rd, etc.. Then use the combine tool to basically union all the euclidean allocation grids?

AFAIK there is no way to calculate the euclidean allocation for anything else than the closest:

[ATTACH=CONFIG]26544[/ATTACH]
this is what my euclidean allocation grid looks like (zoomed of course). It is showing precisely the which cell belongs to which turbine but it is using the SHORTEST way to do that. So all I can derive from that is that if a person would stand in that cell he would see this turbine as the closest. But I need to determine which one comes after that, and after that and so on. Because it would bother more if there are two wind turbines. BUT: this relation is NOT linear.
a possible view could look something like this:
[ATTACH=CONFIG]26546[/ATTACH]
If it wasn't for the distance I could just add up the zones, but it makes a huge difference if you see one real close (and therefore big appearing) turbine or 6 ones that are far away and therefore small appearing.

Maybe it would just be easier to make a bunch of seperate viewshed rasters and then combine them together.... then cursor through the table and work out some sort of scoring system.

I cannot do that because if I merge them, the overlays (the parts where you see more than one turbine) are lost, and if I use the union tool it crashes. And even if it wouldn't (f.e. when I do this with polygons in small steps) the union analysis takes about 3 minutes per 10 viewsheds. so even if the calculation was over after the union (which it isn't) it would take 3 mins * 15,5 *155 = 120,125 hours
If you have questions please ask. I'm glad that you are helping.

Anonymous User · ‎08-07-2013

Original User: csny490

How about this:

1. For each tower make a viewshed raster and then score/reclassify it how you want (this is represented by the 1st image in your original post). So if tower id = 23, you should have a raster that is named something like "viewshed_23". For the analysis extent (the area that encompasses all the towers, reclassify your NoData pixels to 0s. You can use something like Con(IsNull("viewshed_23"), 0, "viewshed_23") to accomplish this. You have to make use of the envr "analysis extent" and "snap rastrer" settings to make sure that the calculation is done right. So in the end, you should have a bunch of rasters that all have the same rectangular extent, do not have any NoData pixles, and have only values 0,1,2,3, etc. - the 1,2,3,... representing your viewshed proiximity zones, and the 0s representing areas that are otside of the viewshed.

2. Now that all your raster have the same rectangular extent, and all the NoData pixels are now 0s, you can use the Combine tool, and end up with a table like this:

VIEWSHED_1  VIEWSHED_2  VIEWSHED_3
0           1           1               
0           2           0
0           3           0

Then you will need to add a field called "SCORE" and run an update cursor to read the VIEWSHED_* values and evaluate them. Maybe just the field calculator will suffice for this, but probably not if you have a whole bunch of towers.

ChrisSnyder · ‎08-07-2013

BTW: I like the look of wind towers - I think they are cool - I just don't like the sound downwind of them!

MattSayler · ‎08-07-2013

Maybe something from the Spatial Statistics Tools? Seems like something in there might be able to take care of the distance issue (maybe Geographically Weighted Regression?).