Trying to get Raster Attribute image in a feature layer.

[MarkSmith]

Hello,

I have a point layer loaded into my SQL SDE database and one of the fields is a Raster type.  I have created a couple of points in this layer and edited the attributes using ArcEditor including uploading a picture to each point into this Raster field.

What I'd like to do now is programmatically get to the image so I can display it on-screen in my JavaScript API and do other stuff with it when it comes to printing.  The problem is I can't seem to find any information on how to retrieve the actual image which must be stored somewhere in SDE.

Using the Identify Task I can get to the other attributes fine, but I just get a value of <raster> back for the field containing the image.

Can anyone please show me where to find out how to do this, or please explain it?  Some JavaScript method is preferable, but I'll settle for dot net if that's the only way (e.g. by using the objectid to get the image from SDE server-side).

Hope that's clear?  Thanks, Mark.

[KenMorefield]

Hi Mark,
I haven't looked into this very far, but you might look at some of the "editing" samples such as this one - here

This sample, and a few others in the editing section, allow the user to add/view/delete attachments (photos, documents, .pdf's, etc.)  You might explore this option for maintaining your photos...

Ken

[MarkSmith]

Thanks, I hadn't found that sample.  However looking at the URL of the hyperlink the dijit creates, I can understand all of it except the last number: http://sampleserver3.arcgisonline.com/ArcGIS/rest/services/SanFrancisco/311Incidents/FeatureServer/0...

5505779 is the objectid of the feature in layer 0, but I assume 8867 is a reference to the id of the uploaded image to that feature, but without using the dijit, I wouldn't know how to get that number.

Thanks again.

[KenMorefield]

Read up on attachments in ArcGIS 10.1 here

It explains that attachments are stored in a separate table to allow for a 1 to many relationship.  I think the 8867 might be referring to the id of the attachment in the related table...

Ken

[MarkSmith]

Hi,

Having looked at the article on attachments, I think this is different to what I have.  I am not using the attachment toolset with a match table, I simply have a Raster field type in my layer's base table that I defined when I originally created the layer and fields in SDE.  It is the image loaded into this field I want to access in my API.

Thanks again, Mark.

[KenMorefield]

You might take a look at this old javascript api sample from a few years ago... This sample utilized the old ArcPhoto add-in, and if I recall correctly, there was some code for pulling rasters out of a field in your geodatabase and including them in your application's info window... LINK

Ken

[MarkSmith]

Thanks again.  I've taken a look, and as well as using the API as a front-end, this seems to make use of the Web ADF server-side - something I'm trying to purge my systems of.  It seems very complicated for what I hoped was a simple thing.  But perhaps I'm starting in the wrong place - maybe I should make use of the attachment toolset rather then a raster field type?

Mark.

[KenMorefield]

Hey Mark,
I'm really not fully up to speed with attachments and storing rasters in fields... but I think the attachments tools that I pointed you towards the other day might be your best direction at this point.  I think they perform the same as what you are currently doing, but instead of storing the rasters in a field in your feature class, I believe they get stored in a field in a table that is related to your feature class - in a one to many relationship.  If I understand correctly, your setup now will only allow a one to one relationship, unless you created many different fields to store rasters in.  The attachment tools will create the relationship to the related table for you.  This is the direction that the current ESRI samples have gone, using the attachment editor.  You might have to reconstruct the work that you've done thusfar, but it might make it easier/better in the long run. 

Ken