4

I recently imported a feature class from a File Geodatabase to an Oracle SDE Geodatabase. The features of the two feature classes now look drastically different despite not having any edits made. enter image description here

The green polygon is the original feature as it looked in the file geodatabase. The purple transparent polygon on top is the feature after being imported into the Oracle SDE Geodatabase. It's as if the act of importing the feature class simplified the features.

Any ideas on why that would happen? I am new to Oracle and ArcSDE, maybe I set something up incorrectly?

Here is another view of the same area, with different symbology: enter image description here

The storage format is ST_GEOMETRY, and there was no conversion performed, as far as I know, I simply imported the feature class into the Oracle SDE geodatabase from the file geodatabase.

Improve this question
4
  • Side-by-side presentation, or both layers 50% opaque with diagonal hatches in different directions would make it easier to guess at the problem. You should also update the question to include how you did the conversion, and the storage format of the layer (ST_GEOMETRY, SDO_GEOMETRY, or SDELOB). This may come down to the coordinate reference parameters, but you can start with the coordinate system.
    – Vince
    Commented Aug 21, 2014 at 21:44
  • I edited the question to answer your questions. The only thing I did was import the feature class, there was no conversion.
    – MMB
    Commented Aug 21, 2014 at 22:16
  • Yes, certainly, conversion was performed, from FGDB to Oracle ST_GEOMETRY, using Desktop, not something else? Was the FGDB source derived from a CAD drawing? How are you accessing the table, from Query Layer or through a geodatabase connection? What is the coordinate system of this data?
    – Vince
    Commented Aug 21, 2014 at 22:35
  • 1
    What method did you use to get the data into SDE? Export/ import in ArcCatalog or Copy/Paste? What happens if you try an append instead?
    – Dowlers
    Commented Aug 21, 2014 at 22:52

2 Answers 2

Reset to default
3

The two most likely causes (that I can think of) are;

1) The SDE Geodatabase configuration keyword includes a PRECISION statement and you likely have converted the feature class form high precision to single precision. -- In most storage projections (we use Stateplane, for example) there is insufficient precision to get fine detail so vertices coalesce and shapes morph. NOTE that configuration keywords are used when using "copy/paste" to move geodatabases into- and out-of SDE.

2) The ArcCatalog environment settings >> Coverage section includes a Precision option for the default when creating new featureclasses. Similar to the keyword option above, the precision should most often be set to DOUBLE so that the coordinates for new featureclasses have sufficient numeric precision to handle fine geometric details.

So, check the environment settings on your client software (ArcCatalog > Geoprocessing > Environments... > Coverage > Precision) and work with your SDE administrator to review the KEYWORD settings.

As a quick test to determine if SDE is or is not the problem, try to copy/paste this featureclass from your source File GDb to a new Personal GDb. This process will make use of the Environment setting for new featureclasses and has nothing to do with SDE. If you get the problem results, then you know the problem is NOT SDE, but is your client software.

Improve this answer
2
  • It's no longer possible to create BASIC coordinate reference precision layers with ST_GEOMETRY storage; even if you request BASIC, HIGH will be used instead. I forget if this was a 10.1 or 10.2 feature, but option 1 is not possible. If the coordinate system is correct, then the scale should be set to 1-0.1 millimeters (which is actually too fine for most data); if the coordinate system is wrong (PCS when it should be GCS), then the 1000 xyscale could generate ~111m coordinate resolution.
    – Vince
    Commented Aug 22, 2014 at 1:57
  • There are a myriad of potential coordinate system proplems which could have these results. I quickly retested both Single and Double precision featureclass creation in 10.2 client and server; both still function as described in my answer but I didn't use ST.
    – JasonInVegas
    Commented Aug 22, 2014 at 6:42
3

It turns out that it was a problem of tolerance and resolution. When we created the feature datasets in the SDE geodatabase, we were simply accepting the default XY tolerance and XY resolution, which was not as precise as we needed it to be. We created new feature datasets and manually set the tolerance and resolution to match that of the feature class as it was in the file geodatabase and then re-imported the feature classes. When we did this they were no longer being simplified!

Improve this answer

Your Answer

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

Not the answer you're looking for? Browse other questions tagged or ask your own question.