One thing that is certain is that if your plan is to implement a multiple software environment with oracle spatial as the backbone, you will not be able to sit on 1 (old) software version. When the user finds all the undocumented features in the software to apply oracle SRID to features then there are differing system 'names' in each software which can and does then result in scaling, display, symbol size, editing problems.Īll of this said.

Coordinate systems are not standardized between all different vendors. If you use SQL to drop and recreate indexes, metadata can be corrupted and specific software usage then broken.ģ. That vendors have not yet fully developed the true Oracle methods for handling spatial data management.

ESRI has some it's own problems in regard to this.Ģ. Those don't have any bearing on the oracle spatial data but when using sql to update a set of rows the addressing of updating the metadata specific to the vendor cannot be addressed by oracle. autodesk has metadata tables that track the dwg name, dwg layer name, color. That each vendor develops a schema that answers direct needs to their software e.g. Some of the problems with each client having it's own interface into oracle SDO are.ġ. The interface in map 2004 is not being developed any further by autodesk. I have used map 2004 to experiment with the use of spatial data in oracle.

Autodesk map 2004 tutorial pdf