Archive for July 23rd, 2016

Jul 23 2016

Esri ArcGIS Pro 1.3

Published by under GIS in general,Vision Statement

For this blog I’m starting a bit of new direction by focusing on Esri tools with available data. Having just completed a draft final version of what will become public-domain building footprints, I’m starting to create 3D City mapping at Level of Detail 1, which I’m inclined to express as a version 1.01 of 3D City.

I’m also in Day 11 of quitting ArcMap cold turkey. Or at least well chilled—with three very narrow returns to ArcGIS 10.4.1 for Desktop for a specific use, then return to Esri ArcGIS Pro 1.3 only. A couple of weeks ago we got the last updates to some building footprints. Now after a couple of day’s work, modeled with bare-earth and first-return LiDAR-derived surfaces, we’ve got extrusions, can run the Procedural textures to give the scene a CityEngine look, and have exported a Level of Detail 1 (call it LoD 1.01) multipatch model.

Gathering statistics from LiDAR was approached in a fairly serious way, with 2 ppsm airborne LiDAR modeled on a 50cm grid with Natural Neighbors (which uses tesselation) for each of [all ground-classified points] and [first-return points]. With some smoothing to attenuate any scanning marks, a [1st return minus bare-earth] difference surface was also calculated and called [height]. The height grid was carefully smoothed with an unsharp mask just enough to eliminate airborne scanner noise, while preserving as much tree canopy detail as possible.

The new building footprints were cleaned and sorted by Shape_Area descending, and assigned an Area_ID in the range [1–177023], then the Area_ID was used with the footprint shapes to define a 25cm zonal grid based on maximum cumulative area that was snapped to the 50cm LiDAR-derived grids. These 25cm cells were used for Zonal Statistics to Table, after converting the three input grids to integer centimeter precision. Zonal statistics on the original floating-point meter grids would not yield either median nor majority values, which were considered useful for stable roof height detection. So all available zonal statistics were run on integer centimeter grids (50cm sampled) of bare-earth [gnd], first-return [1st], and a blurred difference [hgt], sampled over zones of 25cm cells representing each of the 177023 building footprints.

I briefly returned to ArcMap to interactively join the three statistics tables in a more stable way. After that, it was great to get back to Pro 1.3 and edit the schema, renaming and reordering fields, and calculating a few key statistics like minimum ground and median first-return from integer centimeters back into floating-point meters. The minimum ground was used to position each footprint at an absolute elevation based on our bare earth model “tsm50cm” for topographic surface model at 50cm gridding, and the median first-return was used to position the roof at an absolute elevation.

On Day 9 of Pro 1.3, I tried to export the shapes with Procedural textures using Layer 3D to Feature Class, and crashed repeatedly. Even with smaller areas of the city. But finally I got down to just Treasure Island, and it worked with some curious anomalies at edges but with attractive Procedural textures. So I exported to multipatch without color or texture, and got a better-shaped result almost instantly. So, I ran the export for about 1/4 of the city again with Layer 3D to Feature Class, exporting the extruded building footprints to enclosed multipatch 3D boxes—and Pro 1.3 did it in five seconds. Feeling ambitious after that success, I ran the whole city for a set of 177,023 footprints, all Polygon-Z that had been positioned at the lowest NAVD 1988 meters, and the Layer captured the extrusion up to median 1st-return. Not only did that multipatch export complete without crashing, the entire city was done in just 20 seconds.

The Procedural textures were very nice to see. They are oh so precise, but for our city the International Building texture is not so accurate. Still, I was able to tune upper floor height very usefully. And on my little department-issue workstation, I saw all eight CPU threads firing on full while the rendering was taking place. Finding ArcGIS Pro 1.3 running multi-threaded in just the right way to fully utilize the workstation while keeping the interface reasonably responsive—it is a very nice balance indeed. I don’t miss ArcMap at all so far!

No responses yet