alter spatial reference of arcsde feature class in-place?

1758
1
07-26-2011 07:22 AM
markcheyne
Occasional Contributor
hi, i want to check if anyone has an opinion on the following.

we have a feature dataset in arcsde/oracle11g that has exhibited unhealthy behavior in recent months. for any user granted SELECT other than the schema owner, trying to view/preview feature class A (which is in a network), you get an insufficient privileges error, that the feature class participates in a geometric network that could not be opened, unless you view/preview feature class B (which is not in the network) first, then you can view A. The error cites a version name and state id, though there are no versions outstanding in the geodatabase. you can view a feature class, but if you try to view its properties via its arccatalog treeview context menu, you get an error 'failed to edit the selected object'.

If I try to edit FC A, I get an error 'the spatial references do not match'.

i started snooping in the SDE schema system tables, and I see that one of the feature classes in the dataset has a spatial reference different from all the others, it lacks Z values where others have them. All other SR properties are the same. this was likely an editor error when creating the FC. Also, the orphan junctions FC has yet another spatial reference, but this appears to be normal. Don't ask me how that sort of thing works, I thought all FCs in a dataset had to share a single SRID. Also, Tthere are dozens of empty A and D tables in the schema, though again, there are no versions.

So, though I doubt it is our only problem, I thought I'd try to reset the offending spatial reference using ArcObjects, the IGeodatasetSchemaEdit.AlterSpatialReference() method in particular. Or, I could edit the SRID directly in the SDE.Layers table? In both cases, I don't think the actual geometries stored for the FC would be changed, is that a problem?

Any other ideas? I'm quite a bit off my resume mucking around in the system tables, though tech support had no answers, the SDE command line tools say the FCs are healthy (though those tools are not geodatabase aware), and I'm the best we've got. Scary isnt it?

Regards, and thanks, MC
0 Kudos
1 Reply
VinceAngelo
Esri Esteemed Contributor
It shouldn't be possible to get in this situation.  All feature classes must have the same SRID in order
to join a feature dataset.

You can't change the SRID of a layer without corrupting the contents of the SDEBINARY, SDELOB,
or ST_GEOMETRY shapes in the table (the integer compression encoding remains the same but the
meaning changes, causing the shapes to shift and scale differently into real-world coordinates).

Your best bet is focus on what changed, and when, to track down who changed things, and how.
Your recovery path would be determined by this.

- V
0 Kudos