Following the release of 10.6.1.1 in October, our distribution partners helped us uncover a few additional issues that needed to be addressed. The issues (summarized below) have been fixed, the installation package has been updated, and the release notes have been revised. The version string visible in the administration window for this version is: 10.6.1.1 (8.9757). The last bit in parentheses is the build number. For reference, the original 10.6.1.1 release is build 8.9469 while the first three issues below were fixed in build 8.9684 posted around November 1st.
- Can’t update metadata transfer fields after ArcPad QuickProject import. When using the “ArcPad QuickProject (import)” project type and workflow, there was no way to edit the metadata transfer field definitions after project creation. This has been resolved and metadata transfer fields can now be defined or edited after project creation and upon clicking “Update Features”, metadata will be properly transferred.
- Could not store single TerraFlex photo URL to string field. At version 10.6.0.1, the ability to store a (single) photo URL for features in the TerraFlex workflow was introduced (in lieu of storing multiple photos as attachments). Configured via a field name string in the system.config file, this feature did not work as intended. This has now been resolved with the caveat being the URL must be used from within a browser window that has current authentication tokens for InSphere.
- Very slow post-processing when using SQLite for the Trimble Positions office database. Some users reported an issue with very slow post-processing times. This issue was isolated to use of SQLite for the Trimble Positions office database and has now been resolved.
- Feature height metadata value does not match Z value in feature geometry. In version 10.6.0.1, we addressed an issue whereby Z values were not appropriately adjusted for differences in reference ellipsoid height during horizontal datum transformations. This change resolved the issue with the Z portion of feature geometries but did not address the issue with feature height metadata. The former was correct while the latter was still displaying the incorrect value. The mathematical difference of these values is the difference in ellipsoid height between global and local datums at that location. This has now been resolved and the value will be correct in both places.
- Vertical accuracy metadata value is always in the distance units of the horizontal coordinate system. Previously, the units on the vertical accuracy metadata value were set based only on the distance units of the horizontal coordinate system of the feature class. For Z-enabled (3D) feature classes that used the same distance units between horizontal and vertical coordinate systems selected, this was fine. However, if there was a difference in unit between the two (say, NAD83 State Plane US survey feet for horizontal and NAVD88 meters for vertical), the vertical accuracy metadata would be in a different unit than that of the actual feature height (Z). In the example given, the feature height (and Z value) would be in meters while the vertical accuracy would be in feet. This has been fixed and now the units on the vertical accuracy will always be the same as that of the actual feature height (and Z value).
Lastly, with regards to the NGS CORS download issue and initial (registry key) workaround described here, this workaround must be reversed in order for 10.6.1.1 to work properly on Windows 7. If the registry key added in the workaround is not removed, NGS CORS base file downloads will still fail with the same SSL/TLS channel error message. This appears to be unique to Windows 7 and the existence of the workaround does not affect 10.6.1.1 functionality on Windows 8/10.