I've a strange issue where I have a versioned SDE geodatabase (SQL) that contains 7 or 8 feature datasets and roughly 20 or so feature classes within them. All of the layers have the following spatial reference:

GCS_WGS_1984 WKID 4326 Authority: EPSG Angular Unit: Degree (0.0174532925199433) Prime Meridian: Greenwich (0.0) Datum: D_WGS_1984 Spheroid: WGS_1984 Semimajor Axis: 6378137.0 Semiminor Axis: 6356752.314245179 Inverse Flattening: 298.257223563

However, one layer in one feature dataset throws warnings when I attempt to edit the gdb, claiming that it or the other layers do not match the data frame's spatial reference (depending on what was added first.) Meaning, this one layer just doesn't 'match' the other layers. More so, features in this layer appear to be shifted to a certain extent.

When I look at the feature extent for this 'odd' layer IN ARC, I see:

Max X: -67.1451770310964 Max Y: 48.7549151660984 Min X: -215.348767986975 Min Y: 13.3773756624525

I've applied the 'recalculate' button already.

However, I also have a map service running on this dataset and when I look at the details page for this one particular layer, I see something odd:

Extent: Xmin: -180 Ymin: 13.77290001454298 Xmax: 180 Ymax: 48.7548295050966 Spatial Reference: 4326 (4326)

The one feature class doesn't even seem to match up with the other feature classes in the same feature dataset, even though the spatial reference properties appear to be identical.

I'm not sure where to begin, especially as this is a large dataset with many relationship classes and services involved.

  • 2
    Remember that a SpatialReference is much more than a coordinate system. You cannot change the spatial reference of an existing layer. If the layer is based on Geometry type, you can create a new table from the old with SQL, then register that with the correct SpatialReference
    – Vince
    Jun 15, 2018 at 19:52
  • @Vince This is a good point. When we first setup this database (probably 10.1 or 10.2), I recall there was some kind of boundary/geometry extent issue in that SQL (and thus Arc) did not like that the data had a global extent. So, the guy that was helping to stand this up created some features as Geometry type and some Geography. And we'd routinely get drawing errors/warning up until 10.3 came out. I'm not a SQL Server guru so I first need to figure out how to identify which type this layer is b/c I have a feeling this is the heart of the problem.
    – MattS
    Jun 15, 2018 at 20:28


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Browse other questions tagged or ask your own question.