2

This is a follow-up question to organizing attribute table: multiple sets of variables per point.

I am working with ArcGIS 10.1, advanced license. My aim was to build a points layer, each point being a weather station in the study area. For each weather station, some data was available, consisting in the winds speed, average direction, air temperature, and the like.

I have created two related tables: one with the actual station points, the other with the data (i.e., variables) organized per month.

Now, I wish to perform some sort of interpolation on, say, the wind speed using, e.g., IDW. I am required to feed into the arcgis' function the feature dataset and Z value field. The problem is that the latter is stored in the related table, which is different from that of the feature class (i.e., station points).

How am I supposed to go on this?

  • Because there is some confusion, it might be helpful if you could post a screenshot of your weather data table so we can get an idea of what is stored as rows and columns. – Chris W Oct 3 '14 at 22:25
1

It's important to understand the difference between a Relate and a Join, and I'm somewhat unclear on the current setup of your data ("organized by month" how - as rows or columns?).

If your weather data is in separate tables for each month or all months are in the same table with a row for each month, with fields called speed, temp, etc. then you would need to use a Relate. This is because for every one station in your points there are many values (records) for the same point ID in the other table.

This is a one-to-many relationship, which ArcGIS doesn't handle well in a Join - it returns the first matching record found and ignores the rest. For this reason a Relate cannot be 'made permanent' via a Join, and why they are two separate tools/processes. A one-to-many is usually addressed with a Query Table, which basically creates a new table with a record for each possible combination from the two sources. For example if you have one station point and that point has six records in the other table, your new table will end up with six different points in the same place (depending on tool options).

If your weather data is in a single table and your fields are more like Jun12_temp, Jun12_speed, etc., then a Join would work because your table would have one record for each station to match each station point, a one-to-one relationship. All the different readings at all the different times would be attributes of a single point, so just Joining that table to the points via Station ID would get you a useable dataset for interpolation - you'd simply point at the desired field for your Z values.

As far as I know, geoprocessing tools cannot access data through a Relate - it's more of a lookup/access/select kind of function than a use/analyze. In order to run an interpolation on specific values, you'll have to do some pre-processing of your data either to create several separate point feature classes or combine all the reading data into a single table with unique field names.

1

My understanding is that you need to make the relate permanent via a join before you can run interpolation. So join the ancillary data. Then right click on the shapefile to export it to a new one and run the interpolation on the new file. A pain but this is how i do it.

  • A Relate cannot be made permanent via a straight Join, as it would only return the first matching record - see my answer for more detail. – Chris W Sep 30 '14 at 20:03
  • Thanks all for your informative reply. @ChrisW: sorry for my poor explanation. The data I have is as follow: I know the position of many weather stations, and for each one I have, among other variables, the wind speed measured at different points in time (Jan, Feb, Mar, Apr etc). Provided that I would like to create an interpolated surface from those measurements (e.g., a map of wind directions in for each single month), I was wondering what was the sounder approach to arrange the data: single vs. two tables? – NewAtGis Oct 3 '14 at 6:30
  • @NewAtGis Single vs two tables again depends on the way those tables are arranged. A Join, as this answer suggests, is the simplest method to get the two datasets together or even create a single table out of all of it as long as the format will work with a Join. It's also the best setup to use (that I know of) to run further geoprocessing. But if your data is currently set up in a way only a Relate will work, you have to make formatting changes to allow a Join. I've posted more info as an answer at your original question. – Chris W Oct 3 '14 at 22:22

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.