Error with z values in ArcGIS ModelBuilder

Error with z values in ArcGIS ModelBuilder

Although the input data has z values the tool "Adjust 3D z values" in ModelBuilder gives

ERROR 000245: The input feature class must have z values

A multipoint feature gets intersected with a polygon feature and then the intersected multipoints get elevated with "Adjust 3D z value". I have already set the properties of every feature in the model to "z-values: Enabled" or "z-values: Same as Input" but this doesn't help. As the model is very big it is not possible to post a readable screenshot.

I'm using ArcGIS 10.2 for Desktop Advanced with 3D-analyst.

Any ideas what the problem could be?

A couple of things to test. You say it has Z values. A feature class can be Z aware but have no Z values. So first thing to test is does your point dataset actually have a number for its Z value? You mention that it is a multipoint dataset. May be its a bug in the tool (I've personally never used it), may be it only accepts single part datasets? Try exploding them into their single parts?

Make Feature Layer / Select / Select Layer By Attribute "Get Unique Values" grayed out in ArcMap ModelBuilder [10.8.1]

I’m trying to extract road segments from a feature class through ModelBuilder in ArcMap 10.8.1 based on attribute queries, but the "Get Unique Values" button does not pull up a list of values when I click on it. Of the three tools that I have tried for this (Make Feature Layer, Select, Select Layer By Attribute) they all produce the same non-result.

Below is a screenshot that shows the tools I’ve used leading up to the selection step, and what happens when I try to "Get Unique Values" from these various tools. I know that sometimes ModelBuilder is fussy about which selection tool is used based on whether the data is a feature class or feature layer.

Can someone tell me what is happening and how to make it work?

Cross-posting from GeoNet to try to reach as many people as possible!

I should mention that if I try to manually type a query into the main Make Feature Layer, Select, or Select Layer By Attribute tool, it won’t verify.

Still haven’t figured out the initial problem, but I did find a workaround by inserting a Calculator Expression from the Create Variable option and linking it to the tool. Hopefully this is helpful!

Error with z values in ArcGIS ModelBuilder - Geographic Information Systems

An address point layer suitable for use in a GIS.

English 20210322 Schoharie County

(518) 242-5029 [email protected] NYS GIS Program Office

From March 2012 through April 2015, the NYS GIS Program Office (GPO) created a statewide authoritative GIS address point database to support Next Generation 9-1-1, geocoding/address matching, and many other purposes, including public use. The data was built from the best available local and state sources and was supplemented with contractor sources. For the address point build, the State issued a contract for the placement of “Primary” (main structure) address points with addresses parsed in NENA’s Civic Location Data Exchange Format (CLDXF) standard. The main goal was to place the points on building rooftops, however wheren multiple structures exit and it was unclear which one was the primary structurethis was not possible, driveway points were placed. Parcel centroid points were placed for vacant but validly addressed parcels. The GPO QA/QC reviewed each County deliverable using ANSI standards, validating the positional accuracy and attribute accuracy of each address point in a statistical sample of randomly selected points. The sample size and the number of allowable errors for acceptance were based on ANSI/ASQ Z1.4-2008: Sampling Procedures and Tables for Inspection by Attributes. Any deliverable that did not pass the GPO’s QA/QC review was rejected, reprocessed by the contractor, and redelivered to the GPO for QA/QC review. Once a data maintenance partnership has been established with a county, the county can continually provide updates through the GPO’s online data editing application or the county provides an updated copy of the data to the GPO on a regular basis and the GPO incorporates the updates into the statewide file.

Release notes for 100.5

This page provides details about enhancements in the 100.5 release of ArcGIS Runtime API for Qt. It also lists this release's deprecations, resolved issues, and known issues.

This section describes new features and improvements.

  • Mobile scene packages are now supported in the ArcGIS Runtime allowing you to take scenes and their associated data offline. You can consolidate scenes and their data into a single *.mspk file using ArcGIS Pro 2.3 or higher and share the package with your ArcGIS organizational account or copy it directly to your mobile device.
  • Maps can now be rendered with support for reference scale. Reference scale is the scale at which symbols and labels appear at their intended, true size. As you zoom in and out beyond the reference scale, symbols and text will increase or decrease in size relative to the reference scale to keep a consistent size on the map. If no reference scale is set, symbols remain a constant size on the screen and do not change size as you zoom in or out. Individual layers in a map can opt in or out of honoring the map's reference scale.
  • Annotation layers are now supported for display in maps. Annotation allows you to precisely control the placement and layout of text and is often used as an alternative to labels which are more dynamic. Annotation layers can be included for offline use in mobile map packages created from ArcGIS Pro 2.3 or higher or accessed over the network through Feature Services from ArcGIS Enterprise 10.7 or higher.
  • Group layers are now available. Group layers combine multiple layers that are often displayed and managed together. You can create group layers locally from scratch in maps and scenes. Currently, saving group layers is only supported in web scenes.
  • Point Scene layers are now supported to provide fast visualization of large amounts of 3D point features from ArcGIS Scene Services, Mobile Scene Packages (.mspk file) or Scene layer packages (.slpk file). Point scene layers use automatic thinning to improve performance by not displaying all the features at greater distances, rather, as you zoom in, additional features are displayed until you reach the highest level of detail, when all features will be shown.
  • Point Cloud layers are available to support the display of sensor data such as LiDAR from ArcGIS Scene Services, Mobile Scene Packages (.mspk file) or Scene layer packages (.slpk file).
  • Displaying subsurface content is now supported in scenes allowing you navigate that camera below the terrain and explore the data underneath. You can change Surface.navigationConstraint property to allow navigating below ground or you can change the opacity of the surface to view subsurface content from above the ground.

ArcGIS Runtime now supports OGC Web Feature Service, including versions 2.0.0 and 2.0.2. You can:

  • Connect to a WFS service and discover the available datasets
  • Query data from a WFS service and display in a 2D map or 3D scene
  • Query and load non-spatial datasets
  • Use XML to perform advanced queries on the server

At 100.5.0, Runtime does not support editing WFS, taking WFS offline, opening WFS from a portal item, or reading and writing WFS from web maps and scenes. Runtime does not support complex features (those with nested attributes), which may affect INSPIRE services. Some geometry types, including those with Z and those with M, are not supported. When loading a WFS feature table, fields with names that start with gdb _ will be ignored. When populating a WFS feature table from a service, the QueryParameters WhereClause is only supported on services that accept CQL_FILTER, which includes GeoServer.

  • New Multi-layer SymbolsAPI offers more flexibility and control over how to construct and represent symbols. These symbols can be composed of a number of different symbol layers that are combined together along with geometric effects to achieve high cartographic quality. The API closely mirrors the definition of symbols in the Cartographic Information Model spec.
  • Arcade expressions on renderers in a web map or mobile map are now honored in ArcGIS Runtime. Expressions can be used in place of raw field values on these renderers to support smart mapping styles such as Predominance, Relationships, etc. These expressions can be authored using ArcGIS Pro or the Map Viewer web application in ArcGIS Enterprise or ArcGIS Online.
  • 3D Line symbols such as volumetric tubes are now supported when displaying feature layers containing polyline geometry in web scenes.
  • You can now choose to use an existing basemap that is located on the device when taking a map offline. This feature, called by reference basemap, removes the overhead of downloading a basemap for every map and is available for both the on-demand and preplanned offline workflows. The path to the basemap can be an absolute path or a path relative to the mobile map package.
  • Image and vector tiles can now be downloaded from ArcGIS Online services using a polygon as the area of interest. This gives you greater precision to request only the tiles you need to support your operational data. This polygon support is available through ExportTileCacheTask , ExportVectorTilesTask and OfflineMapTask . ArcGIS Enterprise services already supported polygonal areas of interest with prior versions of Runtime.
  • The new Compact Cache V2 format of tile packages ( *.tpkx file) available with ArcGIS Pro 2.3 is now supported in the ArcGIS Runtime. This format is based on an open specification and is optimized for fast access and improved performance. You can use the existing ArcGISTiledLayer and TileCache APIs to support the new format. See Take a layer offline topic for more information on tile packages.
  • The ExportTileCacheTask and OfflineMapTask now support exporting tiles from an Image Service to support offline usage.
  • Time-based expiration of mobile map packages and mobile scene packages is now supported in ArcGIS Runtime. An author can choose either a hard expiration where the package is not usable after the expiry date, or a soft expiration where a warning message my be displayed to the user but the package is still usable after the expiry date. Packages with such expiration constraints can be created using an upcoming version of ArcGIS Pro.

The next generation locator format ( .loc file with associated .loz data) available in ArcGIS Pro 2.3 is now supported in runtime. It offers better result matching, faster offline performance and a more compact file storage. All capabilities available with the previous format such as finding addresses, locations, and suggestions are supported with the new format using the same LocatorTask API.

Coordinate systems, projections, and transforms

  • Coordinate systems—The projected coordinate systems for Las Vegas, Pima County, Serbia, and Saudi Arabia were added.
  • Projections—The Equal Earth and Peirce Quincuncial projections were added.
  • Transformations:
    • Transformations for Slovenia, Saudi Arabia, Georgia (country), St. Pierre and Miquelon, Switzerland, and 19 others were added.
    • File-based geographic/datum transformations were added for Belgium and Switzerland. These files are part of the projection engine .zip file that can be downloaded from your dashboard (requires sign in).

    A number of enhancements have been made to conserve the amount of application memory required to display 3D scene layers. These enhancements include:

    • supporting compressed ETC2 textures for mobile devices. ETC2 textures can be authored with ArcGIS Pro.
    • releasing texture memory more aggressively
    • using pre-defined or on-the-fly oriented bounding boxes (to improve culling of data not required to be rendered)
    • optimizing data structures for vertices and indexing them to reduce redundancy
    • and many more.

    These enhancements have led to a memory reduction of 40-50% in many cases.

    Local server compatibility

    The new Local Server version 100.5.0 works with ArcGIS Runtime 100.5.0 and supports ArcGIS Desktop 10.7 and ArcGIS Pro 2.3. See Local Server Geoprocessing tool support topic for the list of Geoprocessing tools supported at 100.5.0.

    Changes to feature selection API

    These methods that were deprecated at 100.4.0 no longer function at 100.5.0:

    • Selection of features and graphics has been completely redesigned and overhauled in order to improve performance by taking advantage of the GPU and also to accommodate new functionality in this release such as annotation and reference scale. As a result, the appearance of selected features and graphics has changed from previous releases. Visually, selection is now more bold, and displayed on top of all content in a map view or scene view rather than on just the selected features or graphics, making it more distinguishable and easier to spot in bright ambient light conditions. Read more about this change in this blog post.
    • Starting from version 3.0 of mobile map packages, maps are returned from the package in the order in which they were added to the package, rather than alphabetically.
    • Default parameters for taking a map offline using on-demand and pre-planned workflows are now based on the options chosen by the map author in the offline settings of the web map.
    • Surface now returns elevation from the top most elevation source (i.e the source that was added last) when two or more overlapping sources contain information for the same location. In previous releases the bottom most source was used. This change now makes it consistent with how elevation data is displayed in a sceneview for overlapping sources, and is also consistent with how content is returned from operational layers (for example, in identify operations)
    • When opening web scenes, scene layers containing integrated mesh data in the I3S format are now returned as IntegratedMeshLayer type instead of the generic SceneLayer type that was previously used.
    • Visibility analysis such as Viewshed and LineOfSight are now computed based on the geometry of the observer/target. Previously, the analysis was computed based on the center of the symbol used by the observer/target

    Support for iOS 10 was deprecated in a previous release and ArcGIS Runtime SDK 100.4.0 was the last release to support it. A minimum of iOS 11 is required at 100.5.0.

    Support for macOS 10.12 (Sierra) was deprecated in a previous release and ArcGIS Runtime SDK 100.4.0 was the last release to support it. A minimum of macOS 10.13 (High Sierra) is required at 100.5.0.

    Support for Ubuntu 14.04 was deprecated in a previous release and ArcGIS Runtime SDK 100.4.0 was the last release to support it. A minimum of Ubuntu 16.04 is required at 100.5.0.

    Error with z values in ArcGIS ModelBuilder - Geographic Information Systems

    Motor vehicle crashes (MVC) are a leading cause of injury among older adults (586 daily) in the United States 1 and MVC deaths have steadily climbed over the past decade, along with an increase in crash risk with each year 2 . Coupled with the growth of the aging population and the increasing prevalence of dementias like Alzheimer disease (AD), being able to predict when driving performance will decline may prevent crashes and deaths among older adult drivers and others who share the roadway 3 – 5 .

    To this end, our research program seeks to better characterize the driving behaviors of older adults and predict the onset of driving difficulties so that we can implement appropriate interventions to maintain safety and prolong driving life 6 . We are particularly interested in the association between preclinical AD measured using molecular biomarkers such as levels of Aβ 42 and tau in the cerebrospinal fluid 7 , as well as imaging of amyloid 8 and tau 9 lesions in vivo .

    Road tests and driving simulators are the most common and dominant measures used to assess driving performance and determine road safety 10 . Both methods have proven reliable and valid in evaluating poor driving performance and estimating crash risks for older drivers 11 , 12 . However, driving is an overlearned task and controlled conditions like the road test and simulator may not reflect driving as it occurs on a daily basis or expose errors made by experienced or cognitively-normal drivers outside of these controlled conditions 13 . Other limitations of both methods include rater subjectivity, anxiety (poorer performance), Hawthorne effect, dedicated single site measures, simulator sickness and high equipment cost, maintenance, and programming 13 – 16 .

    Due to these limitations, we sought to find an objective, cost-effective method that would allow us to assess future research of driving performance longitudinally on a daily basis among hundreds of older adults in the actual environments that they drive, something that has been unavailable until now. This manuscript describes the first step in our work to adapt a commercial global positioning data acquisition system (GPDAS) and develop a methodology to evaluate driving performance. This technology is capable of collecting data at a constant rate over any determined time. However, due to the cost of data storage and greater programming time with larger volumes of data, we sought to determine the “optimal” time interval for accurate data collection using GPDAS devices.

    The GPDAS device (G2 Tracking Device TM Azuga, Inc) is compact (length = 1.7”, width = 1.8”, height = 1”, weight = 1.1 ounce), plugs into the on-board diagnostic systems port (OBDII) and uses the vehicle’s own battery to supply the 12 volts required to function. Only vehicles manufactured in 1996 or later are compatible with the device. The device’s wireless capabilities include use of third generation mobile phone network (3G), jamming detection, Bluetooth, internal antenna and Firmware-Over-The-Air update for configuration of device firmware. Its global positioning system (GPS) capability includes a 56-channel receiver with a 4-Hertz acquisition rate, accuracy of 2.5 meters circular error probable (CEP) and integrated anti-jamming capability. Finally, it has a tri-axial (X, Y, Z) accelerometer with 8� bits of resolution on each axis. The accelerometer can detect and report changes in acceleration over +/- 16 g-force and the data can be reported at a rate ranging from 1 to 24 Hertz.

    Standard protocol approvals, registrations, ethics and consents

    The GPDAS device sends data at intervals of 30, 60, or 120 seconds, which shows the exact location, speed, and date/time at each interval. The optimal time interval would accurately represent the route traveled using the minimum number of data points possible in order to minimize cost and extraneous data collection. The data collected did not contain any personal or identifying information about the drivers. Ethical permission to conduct this study was sought and received via expedited review from the Washington University Human Research Protection Office who determined that this is a non-human subjects study (201412024). Informed consent was obtained from all drivers who participated in this study.

    After being plugged into the OBDII port, the GPDAS device extracts the signal from the vehicle speed sensor (VSS), which measures the transaxle speed, also known as the wheel speed. The VSS is the reference speed that the majority of a vehicle’s systems rely upon to achieve their specific functionality. For example, the Engine Control Module uses the VSS signal to modify engine functions and initiate specific diagnostic routines, while the variable assist power steering system uses it to regulate power steering pressure for assistance at slow speeds. The speed displayed on the speedometer is generally greater than the actual VSS signal, ranging anywhere between 1𠄳 mph more. The VSS signal, which the GPDAS device uses, is the most accurate reflection of the vehicle speed. Installation takes less than one minute, and once plugged in, the device accesses available satellites for orientation and then begins simultaneously transmitting data to secured servers using available cell phone towers. These data can be then accessed online in real-time or stored in a database for retrieval at a later date. If a vehicle is driven in areas where cellular signal is lost, data continue to be collected and is then re-transmitted when a stronger signal is established. When a vehicle is turned off, the device enters sleep mode but sends a signal every four hours to indicate the ignition is off but the device is still functioning. When a vehicle is turned on, the device immediately begins sending data at a specified time interval. A standard set of data is obtained during a trip, which is specified as the time between when the ignition is turned on and off. These variables include time and date stamp, drive time, idling time, miles, latitude and longitude, speeding over posted speed limit, hard braking, sudden acceleration and an alert if the device was unplugged and plugged back in. Since the device is powered by the vehicle’s battery, if the battery starts to drop below the required 12V, the device sends out a series of alerts indicating insufficient power and will stop transmitting if the power drops below 10V. Additionally, the device will detect problem codes that the vehicle’s computer may send out (e.g. check engine light indicating oxygen sensor requires replacement).

    A structured driving course of approximately seven miles ( Figure 1 ) was designed to represent various real-world driving conditions with a comprehensive mix of stoplights, stop signs, right and left hand turns and merging into traffic. The route began at an office complex in an urban setting and continued several blocks east following a divided boulevard. Drivers then turned south to merge onto a freeway. The freeway section of the route provided driving conditions and associated data logging for highway speeds. Drivers then exited into a large park where the designated route was designed to simulate more rural driving conditions. The park section also allowed for more nuanced driving such as roundabouts where data interval logging could be analyzed for correctness to the real-world, and to simulate driving events such as a U-turn or missed turn. Finally, the drivers exited the park and returned to the office complex starting point driving on surface streets with traffic to simulate additional urban conditions.

    Figure 1. Structured driving route.

    A map of the route was provided to each member of the driving research team, as well as the turn-by-turn driving directions. Drivers did not navigate the route prior to data collection. All GPDAS data were logged into daily csv files with results uploaded to a secured server by Azuga. Automation scripts were used to validate files and copies stored on a secured server. A secured file transfer protocol was designed and automated to transfer the log files from Azuga’s server to our servers on a daily basis.

    Three healthy subjects drove a single course in three different vehicles. The drivers negotiated the course at three different time intervals (30 seconds, 60 seconds, 120 seconds), and at three different times of day, morning (9:00-11:59AM), afternoon (2:00-5:00PM) and night (7:00-10pm). In order to minimize bias associated with the order of driving combinations and day, the time intervals and time of day were randomized for all drivers. Depending on the time of day, data were collected over several days, including weekdays and weekends. Each driver yielded nine sets of data (i.e., all possible combinations of time interval and time of day). The device remained installed in the vehicle without removal until each driver completed the set of routes.

    Data were logged into files (csv) stored in a secure Amazon S3 folder. Data were downloaded in bulk and sorted into folders based on the respective driver IDs. Secondary sorting was done for time interval and filtered for spurious data points. All data were imported to ArcGIS Desktop 10.2 software (Environmental Systems Research Institute, Redlands, CA, USA) and plotted on a map using the latitude and longitude coordinates logged by the GPDAS device ( Figure 2 ).

    Figure 2. GPS points collected.

    Each dataset was queried for a specific time interval, such as 30 seconds. The resulting dataset was used as an input for the Network Analyst extension of ArcGIS. A base road network (edge network) was also loaded into the tool for the routing algorithm. Routing algorithms use an impedance to determine 𠇌ost” of travel on the network, but are often defined in terms of time needed to traverse a given section of the network or distance needed to travel the network segment. The network impedance was defined by time of travel on the base network. The routing algorithm processed all coordinate data from each driving circuit, creating a line representing the path traveled during data collection. These data were then visualized in ArcGIS as lines ( Figure 3 ).

    Figure 3. 1 minute AM routes.

    Each of the time intervals was evaluated for best fit to the base road network. Best fit was determined by comparing the route generated by the routing algorithms to the actual true route of the course. ArcGIS was used to conduct spatial comparisons between the routes driven and the real-world road course or 𠇌orrect” route to determine �st” fit. The results of this analysis were used to determine the preferred data collection interval for the device.

    Results Determining the optimal interval collection for a Global Positioning Data Acquisition System

    Vehicle Name: Participant ID via Vehicle Make and Model Vehicle Speed: Vehicle speed (miles per hour) Latitude: The angular distance of a place north or south of the earth's equator (degrees) Longitude: The angular distance of a place east or west of the earth's equator (degrees) Event Type: Type of event coded by the GPDAS device Timestamp: Date (mm/dd/yyy) and Time (hh:mm:am/pm) Odometer Reading: Vehicle odometer reporting the number of miles.

    The mapped routes were displayed and symbolized by time interval for the main visualization product. In addition to identification of the preferred time interval for data collection, the visualization process also revealed data artifacts and incorrect routing of the base network. The source of these errors was explained primarily by the interval of data collection. For instance, if the data collection interval is too large, the driver may travel through several turns before the next valid data point is logged. This absence of specific data points to guide the routing algorithm may lead to incorrect assumptions, resulting in incorrect path of travel produced.

    As Figure 4 illustrates on the two-minute interval, an incorrect line was generated (zigzag line) due to lack of data about the actual route (red line). Other events, such as hard braking, can also add intermediate data points to aid in the process, but these points are unpredictable and cannot be relied upon for routing protocols since any stimulus from the external environment can impact driving behavior and trigger an event. The 30-second collection interval was determined by the software to have the strongest “goodness of fit” and lowest number of incorrect paths traveled compared to the one and two minute data collection intervals.

    Figure 4. Incorrect routes. Discussion

    This study investigated the optimal time interval for data collection using a GPDAS device to accurately capture a driven route while weighing the considerations of cost associated with data storage and post-processing efforts. The 30-second interval was determined to be the most accurate based on goodness of fit and was affordable for our research program. Technological innovations have led to faster processors and ability to gather greater volumes of data. Yet, the challenges required to analyze big data include large statistical and computational costs, incidental homogeneity, noise, and an inherent requirement to develop newer, robust statistical models to deal with larger sample sizes 17 , 18 . Further, given a stricter funding climate, researchers working with clinical populations cannot afford the time and cost to collect, process and analyze continuous data using existing naturalistic research paradigms. Some studies use in-vehicle data recorders that require hours of installation and extensive modification of participants’ vehicle 11 . Others use in-vehicle cameras which may modify driving behavior and also require hours of post-processing and extensive rater training 16 , 19 . Larger studies that collect hundreds of hours of data may require participants to regularly return to the study site and have the data from their vehicle downloaded 20 . Studies using smart phone applications require participants to charge phones, turn the phone on and off and to remember to bring it in the vehicle when driving, thereby elevating participant burden 21 .

    As a whole, driving research and crash prevention research is shifting toward the use of naturalistic methodologies for evaluating driving performance 22 – 25 . Development and interval testing of a naturalistic driving methodology to evaluate driving behavior is required to measure real world driving conditions and responses 26 in a variety of clinical populations. The methodology presented here implements a non-obtrusive device installed in the OBDII port of a vehicle. The device stores locational data in the form of latitude and longitude at each time sampled, as well as driving behaviors that may occur at any time, such as hard braking, speeding, and vehicle on/off events. Since all data are tied to a spatial location, it is possible to understand the “place” of where data have been collected.

    It is important to note that driving events such as “what happened at this exact moment or day?” should not be singled out. The inherent value of longitudinal data collection is to collect data to better understand changes over time for an older adult driver that may be otherwise hidden from observation. The true potential of this methodology is that data gathered could be linked to other databases to answer a number of questions. One can link weather and meteorological databases to understand the impact of the weather on driving patterns and Department of Transportation databases on road construction to explore how roadwork influences driving navigation. Driving behavior for clinical populations could also be evaluated in a pre-post design for patients who have had medication changes, surgeries, stroke, undergoing chemotherapy or radiation, a diagnosis of seizures or a range of neurological conditions that ultimately impact driving for a brief or longer period of time. Naturalistic driving research has the potential to study and aid the management of driving behavior of older adults with chronic neurological disease like dementia. The long-term goal of our program is to model driving behavior and driving risk of older adults using this naturalistic driving data to identify driving decline over time and develop educational interventions to improve driving performance, decrease vehicle crash risk while driving and structure driving retirement for older adults with a higher risk for MVCs.

    The data referenced by this article are under copyright with the following copyright statement: Copyright: � 2016 Babulal GM et al.

    Data associated with the article are available under the terms of the Creative Commons Zero "No rights reserved" data waiver (CC0 1.0 Public domain dedication).

    F1000Research : Dataset 1. Determining the optimal interval collection for a Global Positioning Data Acquisition System, 10.5256/f1000research.9150.d128877 27

    Informed consent was obtained from all drivers who participated in this study from Washington University Human Research Protection Office.

    Release notes for 100.2

    This page provides details about enhancements in the 100.2 release of ArcGIS Runtime SDK for iOS. It also lists this release's deprecations, resolved issues, and known issues.

    • Use URLs without a GetCapabilities query string.
    • WMS versions 1.1.0, 1.1.1, and 1.3.0 are now supported. Previously, only 1.3.0 was supported.
    • You can now set the visibility of WMS sublayers.
    • This release supports mobile map packages that contain raster datasets and tile packages. These mobile map packages can be created with version 2.1 of ArcGIS Pro. If you load an MMPK's map (explicitly or by passing it to the map view), an AGSRasterLayer or AGSArcGISTiledLayer is created to display the raster dataset and tile package, respectively.
    • To access the mobile maps package's raster dataset you need to unpack the mobile map package first.

    3D scene support for tiled layers in WGS84

    3D scenes now support the use of WGS84 based tiled layers as a basemap or layer. Previously, scenes supported only tiled layers that used the Web Mercator projection.

    A new WMS layer is available that can display content from OGC-WMS services in maps and scenes. You can identify features that are displayed, and generate a legend for them. Only WMS version 1.3 is supported at this release.

    A new ENC layer is available that can display content from ENC (electronic navigational charts) data in S-57 format. ENC is a vector chart that conforms to the IHO specifications contained in Publication S-57, which is a transfer standard for vector data. The ArcGIS Runtime implementation follows the S-52 Presentation Library 4.0 specification for rendering. You can identify features that are displayed, select features, and change various display settings for view groups, text, and other elements such as isolated dangers, contours, color scheme, and so on. S-63 is not supported at time of publishing.

    Direct read of Shapefile datasets is now supported. Shapefiles can be added as a feature layer for display in maps and scenes. You can also add and edit features in the dataset through the shapefile feature table.

    Support for the OGC GeoPackage format has also been added this release. You can add vector and raster datasets in a GeoPackage to your maps and scenes as feature layers and raster layers respectively. You can also add and edit features in an existing GeoPackage feature table.

    Feature layers can now be rendered dynamically in addition to statically, just like graphics overlays. You can set the rendering mode at the map or scene level via load settings or on a layer by layer basis at the feature layer level. Dynamic rendering improves the appearance and interactivity of features during map or scene navigation. Feature layers containing point geometries are rendered dynamically now by default and their symbols remain screen-aligned in map views and will be billboarded in scene views. Feature layers containing polygon or polyline geometries are still rendered statically by default, but you can choose to render them dynamically to allow for 3D behavior such as extrusion based on feature layer attributes and surface placement based on z values.

    Display performance of graphics overlays has also been improved when updating large volumes of graphics. In some cases, the performance as a measure of frame rate is 2x faster compared to previous releases.

    New multi-layer symbol types have been introduced to better represent working with feature layers that contain advanced cartography. At this release, these symbol types cannot be created by developers but can be authored in ArcGIS Pro and deployed through feature services, mobile map packages, and mobile style files for use in ArcGIS Runtime.

    You can now apply a time extent to map views and scene views to filter the display of content from time-aware layers. Time-aware layers include feature layers, map image layers, and raster layers. You can apply time offsets to time-aware layers, which can be used to compare data over time. You can also specify temporal parameters when querying a feature table.

    With the new Scene Analysis API you can define a variety of analyses to be performed using data displayed in the current 3D scene view, then render results that are updated dynamically. This release includes two types of scene visibility analyses: viewshed and line of sight. Viewshed highlights areas in your 3D scene that are visible from a given observer. Line of sight shows which segments are visible along a line drawn between an observer and a target location. For either type of analysis, the observer and/or target may be moving or stationary.

    The new statistics query API allows you to get any of the following statistics for a specified field in a feature table: Sum, Average, Count, Minimum, Maximum, Standard Deviation, or Variance. In the statistics query parameters, you can define filters for features to include in the statistics (based on attributes, spatial relationships, or time extent) as well as how the results are grouped and sorted.

    Coordinate systems and transformations

    Geographic transformations (or datum transformations) can now be discovered, defined, used in project function of the geometry engine class, and chosen to be used by default. Prior to this release, the most suitable transformations have been used automatically whenever data is projected. A new transformation catalog class lets you look up a list of the best transformations to use when projecting between two spatial references that have different datums. The new method, getTransformationsBySuitability , provides a list of applicable transforms for the two spatial references you provide, ordered by suitability. You can even pass in a specific envelope to get back transforms suitable for that specific area. You can define a transformation by well-known ID (WKID) or create a custom transformation using well-known text strings. You can also change the default transformation that is used internally via gtdefaults_overrides.json . Both equation-based and grid-based transformations are supported. You can use isProjectionEngineDataMissing to determine whether required grid transformation data files are missing. The grid transformation files needed by your app can be downloaded from the downloads page.

    Offline maps—preplanned workflow

    This release enhances on-demand workflows with support for exporting and downloading vector tile packages from vector tile map services hosted by ArcGIS Online or ArcGIS Enterprise. Vector tile packages contain a default style to define how tiles are rendered. Vector tile layers can also reference custom styles as resources in a portal item. This release also supports downloading and applying custom style resources to vector tile layers on the client.

    This release expands your ability to take maps offline with the new preplanned workflow. Offline maps allow your users to continue being productive even when their network connectivity is poor or non-existent. The preplanned workflow supplements the existing on-demand workflow by providing an alternative approach of allowing the map author to define and pre-create offline map areas instead of the field worker. Your field workers can then download map areas as required. With both of these offline workflows, the field worker can synchronize any updates to operational data when connectivity is restored.

    Transactional editing is now supported in the geodatabase and geodatabase feature tables. This allows you to perform a number of edits and then choose to commit all of them together as one unit, or roll them all back if any of them encounters an error. Nested transactions are not currently supported.

    Directions returned by route task and closest facility task are available in 10 additional languages - Danish, Finnish, Hindi, Croatian, Indonesian, Norwegian Bokmål, Romanian, Serbian, Vietnamese, and Chinese (Taiwan). If the requested language isn't available, directions fall back to a default language instead of failing. Furthermore, error messages returned by Route, Service Area, and Closest Facility tasks are now consistent and translated into all supported languages. As part of these changes, some DirectionMessage types (Length, Time, Summary, TimeWindow, ViolationTime, ServiceTime, EstimatedArrivalTime, CumulativeLength) are no longer reported. These messages did not respect platform locale settings for formatting numbers, dates, and times messages, and the information they contained is available through other properties in the results.

    Updated Apple platform support

    This release adds support for building applications using XCode 9, and deploying them on devices running iOS 11 and iOS 10. Xcode 8 and iOS 9 are no longer supported.

    Watch the video: ArcGIS Pro: Applying Symbology to Multiple Layers Using ModelBuilder Iterators