I have feature classes of property parcels that are polygons. My client maintains data about the parcels in a google doc spreadsheet (online) and updates the information regularly. I am required to update this information as it relates to the polygons in ArcMap 10.3. Right now I am doing a simple join to an Excel spreadsheet, which I update by copying the online data into. The problem is that I really need to do a one to many since there needs to be more than one record pertaining to each individual polygon.

I can convert the Excel file to a geodatabase table to then do a relate, but then how do I easily update the gdb table? Right now the only way I can see to do this is update the Excel spreadsheet each week, then re-convert the Excel file to a gdb table, overwriting the previous week, and use a relate within the map doc only; given that a gdb relationship class would be voided if I write over the data table.

The other caveat is that I then export the polygons with the joined data to a KML that is used in meeting. I found that the data in a "relate" does not export but the data in a "join" does export to the KML.

Am I understanding all of the ramifications? Could I use some other method of table (i.e. access table) whereby I can copy/paste new data over old data and not lose links? It almost seems that my only option is to make duplicate polygons and add a suffix -1, -2 for the multiple records. (they are linked by the parcel number)

  • 1
    What are the not real solutions you mention in your first line? I do need to ask why is this being done in Google Docs and not in a database of some description? – Midavalo May 23 '17 at 2:05
  • 1
    And why would you need to start again with a relationship class? Or are you talking about deleting the table and recreating each time? An alternative to that would be to truncate (remove the records) but leave the table, then push the updated records into the table. The relationship class will remain, and as long as you're linking on a non-ObjectID field the records should still remain related after an update. – Midavalo May 23 '17 at 2:11
  • 1
    Spreadsheets are not databases; treating them like they are causes all manner of anguish on a daily basis. This Rube Goldberg-inspired approximation of a database could easily be replaced by a real database, and that database would be much less likely to experience a catastrophic failure (even in the hands of a neophyte admin). It seems that you are asking at least two questions (which is forbidden in our "Focused question / Best answer" model). I suggest that you choose whether you want to use a true relational model or a geodatabase model, and start designing a solution using that model. – Vince May 23 '17 at 3:08
  • Midavalo, I would love to get my clients to work in a database that is convenient for me but that is not an option. I agree it would solve a lot of problems. I have done the delete/reload scenario before, but I was hoping that there was an easier work around since I have 5 tables to update. So it looks like my only option if I am forced to stay with the current source data. I have mentioned to the managers that we need to include better workflows in our scope of work the next go around. Of course the "related" data still won't export to the KML. Thanks for answering, and confirming. – geonerd May 24 '17 at 5:24
  • Vince, I completely agree with you that spreadsheets are not databases, but my source data comes from another company who is a client in another state. I have to work with the material I am given. Thank you for responding. – geonerd May 24 '17 at 5:27

Your Answer

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

Browse other questions tagged or ask your own question.