I'm still loading data into my Enterprise Geodatabase, 10.3.1, on SQL Server 2012R2 on Windows Server 2012 R2, and trying to figure out how the EGDB can best be used to manage LiDAR collections. https://community.esri.com/thread/168592. I moved from a file GDB, a bare earth multipoint set for lidar job that covers 33 sq. mi., two point files for some bathemetry within the project area, and an outline polygon to see if I could duplicate the terrain in the EGDB that I have in a file geodatabase. I used steps in my old script for guidance, but ran them in tools.
gp.CreateTerrain_3d(featuredataset, terrainname, "3", "50000", "")
Added the points to terrain as masspoints, the outline as a clip,
gp.AddTerrainPyramidLevel_3d(newterrain, "ZTOLERANCE", "'1 2500';'2.5 10000';'5 25000';'10 50000'")
When I ran Build Terrain from a client PC with my data owner connection, it ran over the weekend without making any progress, so I killed the process. When I ran Build Terrain from my ArcServer machine, it appeared to be making progress but very slowly. It's been running since 5/23 (today is 5/25) and says "Build pyramid (phase 1): 1780/ 40795". The number is still incrementing but very slowly.
The other thing I tried was from my client PC, copy/paste the feature dataset from the local fgdd to the enterprise gdb. That took 15- 20 minutes, but when it finished the terrain was successfully copied over too. And it has 6 pyramid levels as well. I didn't realize that the original had 6 levels.
I compared draw times in ArcMap on a client PC of the local fgdb version of the terrain and the copy/paste version on the egdb, and they seemed to be very close.
Is this expected behavior or is there something wrong with my setup? What happened to the BuildTerrian within the egdb? Is the copy/paste the preferred way to load Lidar terrains? For future lidar collections, will I need to build them in a file geodatabase, then copy them to the egdb? Is egdb storage of Lidar data advised? Since lidar data would not need to ever be edited anyone, and if there is no performance gain, maybe standard fgdb storage on a windows share is more suitable?