Geodatabase Attachments for large organizations

1022
3
07-24-2012 04:48 PM
Status: Open
JoshuaDamron
Occasional Contributor III
Thank you ESRI for creating Geodatabase Attachments in v10!  Its great to easily connect and access pictures, videos and .pdf construction drawings and much more at their geographic locations! 

However, in its current format adding file attachments to features is only functional for a very small organization, it is viable for hundreds not thousands of attachments.  Many thrid party companies are popping up to fill this much needed niche.  I would appreciate it if ESRI would consider making some improvements to enable larger organizations to utilize adding file attachments as a means to spatially organizing files and documents.  
 
This is a follow up on this forum discussion:  http://forums.arcgis.com/threads/51099-Attaching-files-to-features-Linking-to-multiple-documents
 
Proposed Geodatabase Attachment enhancements: 

1) Why relocate/re-save the file attachment in a geodatabase?

We should be able to click on a feature and open an attached document (.wmv, .jpeg, Word, .pdf, excel, etc.) without having to relocate and save the file to a Geodatabase.  Why create a copy of a document and save it in a geodatabase where accessibility is restricted to ArcGIS? 

In its current design, each time an attachment is added to a feature a copy of the file attachment is saved in a geodatabase.  This means that if 50 utility features were all constructed with the same construction plans, the geodatabase must contain 50 copies of the same document.  Why do we need to create/add a new copy of a document for each feature it is attached to?
 
Typically an organization already has a filing system in place, in some cases files are stored on a secure server.  It is important to attach a document to a feature class from its current server folder location.  This prevents maintaining data at multiple locations (1) geodatabase and (2) original secure location.    This would allow a “living” document to be updated and accessed by non-GIS users.  Currently, to update a document you are required to delete and re-add the document for each feature connected to the newly revised attachment.
 
2) Query which features are attached to which file attachment.

Currently if a document needs to be updated there is no way to know how many features are attached to copies of the document in the geodatabase or how many copies the geodatabase contains. Create an interface which allows the user to view which features are attached to which document. 

3) After hours of attaching documents you can delete them all in one click.

The attachment table/relationship is very easy to create, just a right click in ArcCatalog and tada! However, they are also very easy to delete, just a right click in ArcCatalog and tada, potentially thousands (or tens or thousands) of attachments are gone without so much as a warning popping up…  Perhaps we could at least have an ArcCatalog warning pop up to make sure that the user is certain they want to delete the attachment relationship?
3 Comments
KenCarrier
I too think a M-M relationship seems more logical but I also understand the backend would be difficult to code for every customer/situation. There would have to be some type of validation checks to see if it is indeed the exact same document path. Sounds like it would be do-able but easier said than done. I think Esri would have to track the original document path in a field somewhere in the related table, then if someone tries to attach the same document to another feature there would have to be some type of table scan or query performed to see if the object already exists, if so then do not add the attachment but instead build the relationship assuming they decide to use the M-M relationship. There are some downsides to this approach in that it does corner oneself into only using Esri products to access the information whereas hyperlinks continue to be universal and cross software/browser compliant whereas attachments are an Esri geodatabase functionality. Great idea! The issue becomes many organizations have already purchased DMS(Document Management Systems), are they going to want to store the same information again in GIS? Time will tell I guess if GIS will become the new DMS or not.
MichaelVolz
This enhancement would be very useful for a large organization such as a county government.
ElizabethKinney
Concur. We are trying to use Collector App to collect transportation asset data for the state. Enviromental requirements require 6 pictures per asset. With only 300 collected this quickly resulted in 18000+ pictures we are trying to organize and manage. A way to manage this seperately would be greatly appreciated.