This past summer I recorded the location of a large number of plants I was working with by calculating the distance from each plant to each of 3 tripods for which I have GPS coordinates. I'm trying to use arcgis 10 to reconstruct the location of each of these plants. I don't have the bearing from the focal plant to the reference points, only the distance. So as I understand it, this is a trilateration problem.

I've created the following model:

enter image description here

So I have the three GPS reference points as separate features, and each time I enter the distance from the focal plant to each of these reference points. It creates the three buffers, finds their intersection, and plots a point at the center of the intersection polygon.

enter image description here

Although this works, it is incredibly time consuming (~5 hours to get the first of four populations). I have around 1,300 more samples in three separate populations that I need to map in this way.

I cannot figure out how to make an iterative version of this model, however, in large part due to my inexperience with gis. I have a hard time searching the help documents because the jargon is unfamiliar to me, so I think I just lack the correct keywords.

I have seen this post, but as I searched to see how to convert between UTM and the coordinate system used there, it seemed that would be potentially problematic, and I feel like I'm 95% of the way to the solution with the model I already have.

The most obvious way this should work to me is to have an input feature that contains all of the reference and buffer distance data, and iterating through sets of three, or through a set of files each of which contains three points. However, when I've experimented with entering a table like this:

enter image description here

the intersection tool no longer outputs a single polygon where all three buffers overlap, but instead multiple polygons where there is an overlap between at least 2 of the buffers, like this:

enter image description here

I assume that this is because the three buffers are in a single feature instead of three different features, but why this would create a difference in the behavior of the intersection tool passes my understanding.

Furthermore, I don't seem to understand how to make iterators operate properly--my attempts at using the row or feature iterators always result in only one output representing the last row, even when I use dynamic naming of the output.

Is there some way to create an iterative version of this model, or should I just give up on it and go back to square one? I've struck out asking all of the GIS experts on our campus, none of whom seem to have much experience building models.

Thank you! In reading back through this I appreciate that it is very convoluted. I apologize for the length and for my ignorance--this is what happens when a geneticist pretends to be an ecologist.

  • What format are your input data? For example, is plant ID in column 1, gps unit 1 distance in column 2, gps unit 2 distance in column 3, gps unit 3 distance in column 4? Are you working from a dBASE table? – Aaron Jan 23 '13 at 20:45
  • 1
    For the model I have working currently, I've just entered the three reference GPS points as separate features, and then I'm entering the distance values for each run of the model manually. This is a big part of why it's so time consuming. The underlying data I'm working from is the plant ID, distance 1, distance 2, distance 3, and the GPS data for each of the reference points. I included a screen shot above of my attempt to enter one plant's worth of data as a table, although not a dbase table. – Brian Jan 23 '13 at 20:55
  • 1
    Personally, if I understand the issue correctly, I would try to make a nested iteration within the set of iterations that contain the three records. In python, I would use SearchCursor to grab the first set of three that have an identical ID [{1,1,1},{2,2,2}, so on..] and then iterate through those three records with your MB logic. Then go back and grab the next three, and so on. At the risk of being not helpful, I'm sorry I can't contribute on the ModelBuilder end other than to say it can be exported to a python script and worked on from there. Good luck. – JLP Wisc. Jan 23 '13 at 21:02
  • Actually that is helpful. I had avoided looking at the python script for the model because I'm not great with python and assumed it would be really complicated. In reality it's like 40 lines of code. I wish I'd looked at this a week ago! Writing scripts to iterate over datasets (albeit in perl or R) is like the one programming task I've done before. Thanks! – Brian Jan 23 '13 at 21:12
  • 3
    A solution (including code, explanation of the algorithm, and a link to relevant Python code on the Web) is posted at gis.stackexchange.com/questions/40660/…. – whuber Jan 23 '13 at 21:50