I have a new requirement that, in some 200+ ArcGIS Feature Services on Server 10.6.1 (They are not hosted via a PTL), they all get an "ELEVATION" field and users will somehow magically populate the elevation using a local, Lidar-derived DEM (so it can't be the AGOL elevation service).
Here's what's not going to work:
Use Extract Values to Points (which creates another FC), join back to the original feature service, calculate field using RASTERVALUE: To many steps, users mostly stop understanding the workflow after the word "join". GIS is not these folks job, they GPS some things, add the points to a feature service, need to know the elevation...
The requirement is the Lidar-derived elevation, not the GPS one
Z-enabling everything. Not possible in our environment, nor feasible given the number of SDE feature classes we'd have to modify.
Can't use SQL on the back end like
ELEVATION <SPAN class="operator token">=</SPAN> <SPAN class="punctuation token">(</SPAN><SPAN class="keyword token">SELECT</SPAN> pdata<SPAN class="punctuation token">.</SPAN>getValueByLoc<SPAN class="punctuation token">(</SPAN><SPAN class="number token">1</SPAN><SPAN class="punctuation token">,</SPAN>p<SPAN class="punctuation token">.</SPAN>SHAPE<SPAN class="punctuation token">.</SPAN>Long<SPAN class="punctuation token">,</SPAN>p<SPAN class="punctuation token">.</SPAN>SHAPE<SPAN class="punctuation token">.</SPAN>Lat<SPAN class="punctuation token">)</SPAN> <SPAN class="keyword token">FROM</SPAN> <SPAN class="punctuation token">[</SPAN>dbo<SPAN class="punctuation token">]</SPAN><SPAN class="punctuation token">.</SPAN><SPAN class="punctuation token">[</SPAN>DEM10MP<SPAN class="punctuation token">]</SPAN><SPAN class="punctuation token">)</SPAN><SPAN class="punctuation token">,</SPAN><SPAN class="line-numbers-rows"><SPAN></SPAN></SPAN>
which uses ST_RASTER, an unsafe assembly which we're not allowed to use.
Surely someone (many hundreds in fact) have had this requirement....and solved it? Some python toolbox is out there somewhere......