Take the 2-minute tour ×
Geographic Information Systems Stack Exchange is a question and answer site for cartographers, geographers and GIS professionals. It's 100% free, no registration required.

I am building a file geodatabase using ArcGIS. The gdb is going to be distributed to dozens of 'stand alone' machines. End users are expected to populate the gdb with data. End users do have ArcGIS but vary widely in thier technical savvy. Depending on their business needs, different users will populate different subsets of the database (a few potential combinations). I would like to expose the minimum number of fields to each user while they are entering their data.

I can think of two general solutions, but I don't have a good handle on the pros/cons of each. I'm hoping for feedback in the form of relative difficulty, relative benefits, or better yet... a better solution.

1) ArcGIS "Add-in" form built with Visual Studio
2) Form built outside of ArcGIS (Access, Python/Tkinter, or Internet based) and imported into the end user's gdb from a script within ArcMap

share|improve this question
    
I am not clear what the form/script is supposed to do? Can you please elaborate. –  GuidoS Oct 8 '10 at 19:50
    
The form is intended to show an end user only those values from the gdb that they care about. I am trying to figure out what my options are for creating that form. My gut is telling me to go with option 1 above and I'm hoping for input before I start a brand new learning curve (C#) –  BrianPeasley Oct 8 '10 at 20:22
1  
Writing a GP tool and just using the generated dialog isn't enough? –  Jason Scheirer Oct 9 '10 at 4:37
    
If you go with 1) remember to target the .NET 3.5 framework –  patrick Oct 11 '10 at 17:01
    
Do you want users to add spatial data too? Or is it just fields associated with features? –  djq Dec 10 '10 at 21:39

5 Answers 5

i dont know if anyone here has really explained a method of joining data but, by adding data from your gdb and if you are looking to condense it to a smaller output/input i would use the joining tool but only the information that is relative to that layer so that it may make them smaller and less confusing to the user and the person using the program.

Hope this may shine some light in on what you are asking.

thanks, james

p.s if you have any other questions you may feel free to find me on my fb page. https://www.facebook.com/#!/profile.php?id=693445244

share|improve this answer

One approach is to create a standalone table in an MS-Access* mdb and Join it to the spatial layer(s). You are then free to use all the standard Access tools for creating forms, queries, etc. on the standalone table. The disadvantage of course is that people can't see the geometry at the same time (from the forms interface), so this will only work in some circumstances.

*The same principle can be applied to Excel, Oracle, SQL-Express,...

share|improve this answer

In addition to symbology etc. layer files save the state of shown/hidden fields of the attribute tables. So if the downstream editors are comfortable entering data in table view, set the table display properties to hide the unnecessary fields, save a layer file, and pass the layer file on. It's also possible to set font size, column width, and few other things this way. The same theory applies to .mxd's also.

Note: I'm going from memory. It's possible that when one starts an edit session the hidden fields are shown. So test first.

share|improve this answer

Could you simply turn off the unneeded fields and then let them use the Identify tool? Obviously, this solution is a bit of a hack and doesn't scale well.

share|improve this answer
    
Your comment made me realize that I left out a key factor in my original description. I'm building the gdb schema and I want the end users to populate it with data... So no, this suggestion won't work for me. –  BrianPeasley Oct 12 '10 at 0:02
up vote 1 down vote accepted

Apparently there is no magic bullet for this... Maybe an opportunity for one of you entrepreneurial types?

If I understand the comment from Jason Scheirer above, a fairly simple solution is to write a few GP tools:

1) Make copies of all non-spatial gdb tables
2) From the copied tables, delete attributes that should not be exposed to "Client A"
3) Write an "add record" GP tool for each of the table copies that "Client A" needs
4) Repeat steps 1-3 for each unique set of attributes that you want to expose (Client B, C...).
5) Bundle the GP tools into a tool box for each custom view of the gdb

Cons: The UI won't be pretty & the housekeeping will be tricky business (a change to the gdb, will need to be reflected in all table copies).
Pros: The tools are at hand, I can get busy tomorrow.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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