Do I understand you right :
1) You want for each grain 36 distances to the surrounding grains. One from each sector of 10 degrees, is that right?
2) Those sectors you are defining from the center of the grain (from a comment to celenius)
3) You want the boundary to boundary distance
If I am right so far I think thee is one thing to comment.
Since you are defining the sectors from the center of the grain and want the boundary to boundary distance it will be kind of messy. If we start to do this calculation from grain1 we will first find the center of it, then define the sector and make a distance calculation from the boundary of grain1 to the boundary of the other grains that falls inside the sector. That means that you might get the shortest distance from a point outside your sector on the boundary of grain1 to a point on the boundary inside the sector on the other grains.
This is doable in PostGIS for instance.
But it would make more sense to me to pick on of the following instead (of cpource depending what you are trying to get out of this)
a) take the distance from the center of grain1 to the boundary inside the sector of the other grains
b) Calculate the distance between the segment of the boundary falling inside each sector both for grain1 and the other grains (means you have to extract also the sector part of the boundary for grain1)
c) Find the "shortest line" between grain1 and the others that satisfy being in each sector
The last one is the most tricky
I don't know if it is possible in any GIS-software of today. But in PostGIS it would be quite simple to implement I think. It would be a distance-function with azimuth-restrictions. It would beside the distance also give the coordinates from where the restricted distance is found. That is the beauty with open source. Everything is possible :-)
It would need maybe a day or two to get a working patch and if the community likes it, it would be official by summer in PostGIS 2.0.
If you want to stay with your approach as I have understood it above I can post some SQL-code for PostGIS. (I just had to try it when I saw the question :-) )
Approach a) and b) is also doable quite simple.
And as mentioned also approach c) of course also possible
Update:
Ok, here comes some code. It is a little bit messy that's why I didn't post it at first. There is some parts that I see could be optimized, but it seems to work anyway.
What it does is:
1) finding the centroid of the first geometry
2) making a buffer around that point
3) finding 36 points around the boundary of the circle from the buffer
4) builds slices from those points to the center point
5) Makes an intersection between the slices and the surrounding grains
6) calculates the distance to those intersections.
That's about it, here comes the SQL:
CREATE TABLE result_table AS
SELECT DISTINCT ON (id1, n) id1, dist, id2, n, ST_Shortestline(ST_Intersection(slice, unsliced_geom), orig_geom) AS shortestline FROM
(
SELECT ST_Distance(ST_Intersection(slices.geom, t1.geom), orig_geom) AS dist, slices.geom AS slice, t1.geom as unsliced_geom, slices.id as id1, t1.id as id2, slices.n,orig_geom FROM
(
SELECT ST_MakePolygon(ST_LineFromMultiPoint(ST_Collect(array[the_p, p1, p2, the_p]))) AS geom,the_p, id,orig_geom, n FROM
(
SELECT ST_Line_Interpolate_Point(the_geom, ((n-1)/36.0)::float) AS p1,ST_Line_Interpolate_Point(the_geom, (n/36.0)::float) AS p2,the_p, orig_geom, id, n FROM
(
SELECT ST_Boundary(ST_Buffer(the_p, 1000)) AS the_geom, the_p, id, orig_geom FROM
(
SELECT ST_Centroid(geom) AS the_p, id, geom AS orig_geom FROM the_table
) p
) lw,
generate_series(1,36) n
) points
) slices
INNER JOIN
the_table as t1
ON ST_Intersects(slices.geom, t1.geom) AND slices.id!=t1.id
) t
where id1=1
order by id1,n , dist ;
The WHERE clause makes it only compute against row with id 1. You can just remove that row if you want it to calculate the same thing from each grain.
the resulting shortest line from a small test case:
It can be modified to measure from the sliced part of the "orig_geom" too.
