To forse height in ESRI geodatabase to 0

[ilonaPredotova]

We are running ESRI geodatabase and have got wrong height from the beginning. Somebody who knows how to force all objects in geodatabase to 0 height? Some function? We still want to keep 3D geodatabase.

Thank you

[JakeSkinner]

What type of geodatabase are you using (File, Personal, SDE)?  How many feature classes are you working with?  One option is to use the Feature Class to Geodatabase tool and within the Environments, set the Z value to 'Disabled'.  You could then run this tool again and set the Z value to 'Enabled'.  This will write all of the feature classes to a new geodatabase with all Z values set to 0. 

However, if you have a large geodatabase, need to maintain versioning in SDE, feature classes participate in a replication/topology/network, this will not be practical.

[VinceAngelo]

Forcing all coordinates to have zero Z values will slow down object access by as much as
50% without any real benefit.  If you want to keep a 3-D database you'd need to store
actual Z values.

- V

[ilonaPredotova]

We have SDE geodatabase. We wanted to find some better (easier) solution than to copy the whole database to a new one making the environment settings. There is a lots of data in quite many feature classes...

[MarcoBoeringa]

Forcing all coordinates to have zero Z values will slow down object access by as much as
50% without any real benefit.  If you want to keep a 3-D database you'd need to store
actual Z values.

Vince, it would be helpful to us all here if you gave some background to this. I know that for example Oracle supports spatial indexes on Z and M, but wasn't aware ArcGIS used it. Or do you mean that the mere fact there are Z coordinates (whether 0 or not) stored / defined on the geometries, slows down object access, and it is thus beneficial to switch to 2D X,Y based Feature Classes if no real Z is required?

[VinceAngelo]

When you access a 3-D geometry through the API, it must allocate a SE_POINT buffer for
the X,Y data, and a LFLOAT buffer for the Zs.  LFLOATs (double) are half again as large as
as SE_POINT (struct { double x, double y }).  Inside the object itself, the Z values must
be stored, though all zeros will only add 8+(nverts-1) bytes (which means that the storage
requirements for point layers increases 50%).  Spatial indexes are unchanged, but the
time it takes to retrieve the rows (which represents the bulk of the query time) increases
with larger shapes (this is why a -400,-400,1000000 WGS84 coordref is so much faster
than a -400,-400,1000000000 one).

I'm actually glad it's so very inconvenient to add zero Z values to a large dataset.  This
should raise the question of whether so much work for so little gain is worth the effort.
Calculating actual Z values from a scale-appropriate DEM (be it GTOPO, DTED0, DTED1,
DTED2, or a few petabytes of LIDAR) would also be a lot of effort, but then you would
actually have a 3-D dataset (actually, just 2.5-D), not a dataset with similar storage
and poor performance with no useful values.

- V

[ilonaPredotova]

Sorry, I should have said that I am using this 3D database to save objects to (buildings....) while I am drawing in 3D photogrammetric program. Database has Z generated from GRID which was wrong. That is why I need to remove Z which was wrong but still be able to draw 3D towards this database.
Objects saved in this database will be exported with Z to the separate database. After that I want to remove Z again from the original database.

[VinceAngelo]

Changing all the wrong Zs to 0 won't make them right.  I'd recommend either using
a correct DEM or eliminating the "3" from the layers entirely.  You can still draw 2-D
layers on top of a surface in most 3-D visulaization environments (like ArcGlobe).
Only tables that really contain Z values should have 3-D support enabled.

- V