I have a mobile project running using ArcGIS mobile for Windows. The project is being used by Trimble Junos - in order to allow the Trimbles to collect more than one picture in one location, I named the fields in the DB "Picture_1", ect. This works great as it prompts the camera to open in the Trimble or add a photo that is already stored on the Trimble. The problem I am having is adding the pictures directly into a Flex map so the Flex map is populated with data "live" from the field. My current work flow is:
-Copy the feature class to a personal geodatabase (since it is a Microsoft Access database) -Run a script that extracts the blobs as jpegs to a folder -Have the Flex map call to that folder to display the images
The problem with this is that the data does not feed live to the Flex map. Any ideas? Thanks!
Does your script convert BLOB field data for individual records or does it convert BLOB field data for an entire feature class (or however the entire data set is stored)?
This seems like a duplication of file storage as the data is basically being stored in 2 different formats. Is there no tool in FlexViewer that can currently read directly from a BLOB field and display an item such as a jpeg image that is stored in the BLOB format. That seems like a more efficient system.
Is there no tool in FlexViewer that can currently read directly from a BLOB field and display an item such as a jpeg image that is stored in the BLOB format.
Just to clarify, since the ArcGIS Server REST API does not support BLOBs, that would mean that any of the APIs would also not support BLOBs (e.g. Javascript API, Silverlight API and Flex API)?
Is there any chance that ESRI is looking to enhance these APIs with the ability to directly read/write to BLOB fields? There are many 3rd party GIS software vendors that store data in BLOB fields and it would be very useful to be able to get directly to the data (plus it would reduce duplicated file storage).
Just to clarify, since the ArcGIS Server REST API does not support BLOBs, that would mean that any of the APIs would also not support BLOBs (e.g. Javascript API, Silverlight API and Flex API)?
Correct. And since version 10.0, the best approach for relating images, pdf, word docs, pdf and pther files with a feature is to use "attachments".
Thanks Robert. That is what I was planning to do, I just wanted to make sure I was not requesting an enhancement for a widget (tool) that was already available.
Does your script convert BLOB field data for individual records or does it convert BLOB field data for an entire feature class (or however the entire data set is stored)?
This seems like a duplication of file storage as the data is basically being stored in 2 different formats. Is there no tool in FlexViewer that can currently read directly from a BLOB field and display an item such as a jpeg image that is stored in the BLOB format. That seems like a more efficient system.
Michael,
My script works on a table (does not have to be a feature class) and "extracts" whatever data is in the BLOB field for that record and saves it to a file. Since I already know that all "objects" stored in my blob fields are jpegs, I name it with a .jpg on the end (could easily be a text file, or whatever in a BLOB, so you need to know what you are extracting). The parts of my script I cut out actually look at what images have "changed", and re-extracts only them. Can easilly add whatever logic you need to only extract what you want.
You are correct, it IS a duplication of data, but, is the best solution I have come up with and really doesn't put much of a dent in my 12 TB. As far as server supporting BLOBs, the only BLOBs I know that are supported are attachments as they are stored as BLOBs in a FGDB. Hopefully in the future, ESRI can extend that to non-ESRI BLOB fields as well.
If you have a simple 1:1 relationship, the attachments is probably the way to go, not to mention they automatically integrate with Flex popups. Still a duplication of files, but they are tied to your data.
You could use something similar to my script to extract the images, then use the attachments script to load them directly into the FGDB as attachments without actually saving them locally. However, the way attachments are currently, if you have a 1:many relationship with multiple features in a class, ALL attachments will be "linked" to the first feature in that class, and none of the others will have any attachments at all. I have many photos, and potentially many features per class, so this is the route I chose.
There are several posts on the ideas page suggesting to improve the attachments tool to support a 1:many as well as to allow linking to a folder somewhere for attachemnts (this is a common one, as many people have their photos/etc. already saved somewhere, and don't want to have to copy them into the FGDB) You may want to promote some of these. I voted your latest one up as well.
