LayerNode — This class is an abstraction of the layer object from ArcGIS API for JavaScript. It contains the reference to the parent or child layers and allows you to access layers using a unified interface regardless of a root layer, sublayer, or layer type such as FeatureLayer, ArcGISDynamicMapServiceLayer, KMLLayer, and so on. It replaces the LayerInfo class, which has been deprecated.

LayerStructure — This class reflects the structure of the operational layers in the current map. It can be used to traverse and operate each layer and sublayer abstracted as a LayerNode in the LayerStructure. It replaces the LayerInfos class, which has been deprecated.

Utils — The getDisplayValueForCodedValueOrSubtype method gets the best display value for coded value and subtype fields.

What are DevLabs?

If you are new to the ArcGIS DevLabs, they are short tutorials that step you through the process of building geospatial apps with the ArcGIS platform. They follow a Data – Design – Develop workflow and illustrate how to import data, style maps and layers, and then add maps and layers to applications. The labs are very short (5-15 minutes each) and you can complete them in any order you want and in the language of your choice: JavaScript, Android, iOS, or with any of the Runtime APIs.

New Python Labs – Automate Workflows

There’s more to building apps than coding the apps themselves! The new Python labs show you how to use the ArcGIS API for Python to automate workflows that help you prepare and maintain data for your applications. These labs give you the option of using the Esri Jupyter Notebook in the cloud so no installation is required! You can input and execute Python code right from your browser.

New REST Labs – Enterprise Development

The new REST labs show you how to access ArcGIS Services (Feature Services, Geocoding, Directions…) directly with the ArcGIS REST API, which is extremely helpful when building and integrating ArcGIS Services into larger enterprise solutions. They step you through the entire process of acquiring an authentication token and then executing GET and POST HTTP requests with an easy-to-use tool called Postman. Learn more about these labs here.

Feel free to browse the complete list of the new labs below and start building apps today!

]]>https://blogs.esri.com/esri/arcgis/2017/10/12/arcgis-for-developers-lots-of-new-devlabs/feed/0Thematic point clustering for data explorationhttps://blogs.esri.com/esri/arcgis/2017/10/11/thematic-point-clustering-for-data-exploration/
https://blogs.esri.com/esri/arcgis/2017/10/11/thematic-point-clustering-for-data-exploration/#commentsWed, 11 Oct 2017 15:00:12 +0000Kristian Ekeneshttps://blogs.esri.com/esri/arcgis/?p=88116Continue reading →]]>Extracting meaningful information from large or dense point datasets can be challenging. Sometimes many points aren’t visible because they’re stacked on top of one another. Some datasets contain sparse data in some locations, but very dense data in others. Visualizations of attribute data with color or size in these scenarios can be difficult to digest. Zoom out to smaller scales and all of these problems are compounded. Version 3.22 of the ArcGIS API for JavaScript introduced point clustering to help solve some of these problems. It allows you to reduce and summarize relatively large numbers of data points in the map, providing some insight to geographic patterns in the data. These clusters are scale-dependent, meaning both their size and color change appropriately as the view scale changes.

Perhaps the most compelling piece of the ArcGIS clustering implementation is its separation from the layer’s renderer. Clustering is enabled on the layer, not the renderer, which means that all rendering properties are retained by the layer when clustering is enabled. Once enabled, the popup of each cluster will summarize the attribute used to drive the visualization of each feature. The color and the size of each cluster is determined based on the average or predominant value of the features comprising the cluster. Therefore you can use clustering as a tool for summarizing potential spatial patterns in data exploration apps.

Clustering in the ArcGIS API for JavaScript is enabled outside the renderer, so clusters retain renderer properties and summarize the variable of interest on a cluster-by-cluster basis. In the example above, New York City 311 calls are visualized by the time of day each incident was reported. Cluster colors indicate the predominant time of day incidents were reported among features comprising the cluster.

The toEasternTime() function is a custom Arcade function used to determine the hour an event occurred in the Eastern Time Zone. This assumes all data points were collected in the same time zone in the year 2015.

Then I created three renderers, each based on one of the above Arcade expressions, and added a select element to the UI to allow the user to dynamically switch visualizations on the layer. I also added a checkbox allowing the user to view the visualization with clustering enabled or disabled.

Additionally, the app allows you to visualize and filter incidents by type. This filter allows us to explore potential spatial patterns based on location, type, or any of the time variables mentioned above.

Data observations

After exploring the data, it’s clear how clustering can improve the visualization of points based on a thematic attribute. Take a look at the image comparison below (click the images for a larger view). The renderer depicts the number of days each incident closure was overdue. When clustering is disabled, no obvious pattern emerges. However, once enabled, clustering helps us clearly identify areas where incident closures tend to be overdue more than others. These clustering patterns can be more or less refined as you zoom in and out or adjust the clusterRadius on the layer.

No clustering

Clustering enabled

This app also demonstrates how filtering features impacts cluster patterns. As you filter by various complaint types, you will notice not only different spatial patterns emerge, but patterns in the closure times of each incident appear as well. For example, blocked driveways, illegal parking, and noise complaints usually seem to be resolved quickly and on time. Similarly, broken meter complaints tended to be resolved well ahead of schedule.

But graffiti complaints tended to close much later, often well after the assigned due date. Since “graffiti” is the most common incident type, it heavily influences the overall visualization of overdue incident closures.

On average, street condition complaints were resolved before or after the due date depending on the location of the complaint.

The time of day visualizations seemed to follow expectations when filtering by type. For example, noise complaints tended to occur at night, while blocked driveway complaints occurred more often in the morning, evening, and night (when people are more likely to be going in an out the door).

Overall, blocked driveways were reported more often in the mornings, evenings, and nights than at any other time of the day.

Enable clustering in your web apps

Clustering is managed with the featureReduction option in FeatureLayer and CSVLayer. You can enable it by simply setting the type to “cluster” in the layer’s constructor…

There are several other methods and options available for managing clusters and their children features. See the 3.22 release notes for more details.

Leverage the ArcGIS platform

While the tips mentioned above may help you get started with incorporating clustering in custom data exploration apps, don’t forget to use the ArcGIS platform to your advantage when possible. You can save yourself time by enabling and configuring clustering options in a web map in ArcGIS Online, and loading it into a custom web application. Check out this blog post, which provides a nice summary of the various clustering capabilities available in ArcGIS Online.

A word of caution

Clustering is useful for summarizing and identifying potential spatial patterns in attributes visualized by a layer’s renderer. However, keep in mind that every cartographic visualization includes some level of deception and should be questioned. While the visualizations in this sample show some interesting patterns, they depend solely on my definition of “time of day” and don’t take into account the spread of features as they occur in time.

For example, the time frame for “morning” could be interpreted a number of ways. Does it start at 5 a.m., 6 a.m., or 7 a.m.? When does it end? And regarding the spread of the data, let’s assume that “morning” is defined as (6 am – 11am) and a predominant “morning” cluster contains 500 features. Suppose 250 of the incidents comprising the cluster occurred between 10:50 am – 11:00 am and 240 occurred between 11:00 and 11:10. The cluster would correctly depict the data as predominantly occurring in the morning, but it doesn’t reflect the fact that most features occurred in the late morning, much closer to “midday” than a reasonable person might otherwise assume when viewing this map. Additionally, the visualization doesn’t indicate the strength of the predominant value.

Zooming in and out at various scales and browsing the features of each cluster will help peel away at the inadvertent deception present in the summarized data.

Also note that clustering options available via featureReduction do not perform complex statistical analyses. Therefore, the clustering visualizations described above should not be interpreted as precise, statistically significant “clusters” of data. Rather, they should merely be approached as a nice summary of the data, providing you with a preview to potentially identify spatial patterns that may or may not reveal significant storylines.

If you require more sophisticated spatial analysis, such as attempting to determine statistically significant hot spots and cold spots, or identify clusters of data, then the ArcGIS platform offers several tools that allow you to accomplish this. In ArcGIS Online, these tools include Aggregate Points, Calculate Density, Find Hotspots, and Find Outliers. You can also take advantage of the cluster toolset in ArcGIS Pro for access to additional tools.

Conclusion

Because clustering is a client-side feature reduction solution, it has a number of known limitations (see the list below). Server-side clustering will be implemented in a future release, which will improve performance and allow for more features to be clustered. Clustering will be added to the 4.x series of the ArcGIS API for JavaScript sometime in the near feature. Also check out the samples new to the 3.22 documentation demonstrating various ways to implement clustering in your web apps.

Known Limitations in 3.22

Support is limited to point data in FeatureLayer (from service or FeatureCollection) and CSVLayer.

The map must have a spatial reference of Web Mercator or WGS84.

If the layer contains more than 50,000 features, then only the first 50,000 will be clustered.

A FeatureLayer created from a service URL must point to a service that supports pagination (ArcGIS Server version 10.3.1 or higher).

When editing is initiated with the Editor widget, then feature reduction is disabled until the Editor widget is destroyed.

Feature reduction is disabled when the layer has one of the following renderers: HeatmapRenderer,BlendRenderer, TemporalRenderer, or ScaleDependentRenderer.

]]>https://blogs.esri.com/esri/arcgis/2017/10/11/thematic-point-clustering-for-data-exploration/feed/3Geocoding: Delivering High Location Accuracyhttps://blogs.esri.com/esri/arcgis/2017/10/10/geocoding-delivering-high-location-accuracy/
https://blogs.esri.com/esri/arcgis/2017/10/10/geocoding-delivering-high-location-accuracy/#commentsTue, 10 Oct 2017 16:50:36 +0000patel_nickhttps://blogs.esri.com/esri/arcgis/?p=88184Continue reading →]]>Geocoding is a fundamental GIS process for plotting your data on the map. It is often the first step in applying GIS to understand the where. The accuracy of plotted points directly correlates with the success of downstream decisions. Regardless of the GIS application you choose, you will make decisions based on analysis and this analysis must be accurately geocoded.

To ensure geocoding accuracy, consider these five questions:

How do you define accuracy and why does it matter?

What are the benefits of using a solution built with authoritative,commercial street data versusa low-cost or free solution that uses OpenStreetMap and Census TIGER data?

Which match levels are supported by my current geocoding solution, and what is the benefit of cascading to get the best match at the highest accuracy?

What is the difference between a Address point, Delivery point, and an Address Range match?

What does the status ‘Match, Tie, or Unmatch’ mean and what does the score indicate?

Defining Accuracy

Many people get confused when describing Accuracy and Precision. Sometimes these terms are incorrectly thought to be interchangeable.

Here are the correct definitions. Accuracy is used to describe the closeness of a measurement to a true value. Precision is the closeness of agreement among a set of results. In the graphic below, you can see the differences between each.

This diagram shows the difference between Accuracy and Precision. Geocoding matches can be highly precise and highly accurate as well as inaccurate and imprecise, and anywhere in between. Image Credit: http://www.antarcticglaciers.org/

In geocoding, you can obtain highly accurate, highly precise results or results with low accuracy and precision, or anywhere along the spectrum depending on your solution. Accurate and precise geocoding results are essential for many use cases as discussed in our previous blog. They greatly affect the decisions that stakeholders make with analysis downstream. Many factors influence accuracy and precision, as we will discuss.

Street Reference Datasets and Accuracy

To be able to match a spatial coordinate to your address record, you need a street reference dataset that contains the address and the associated coordinates. This will be used by the software as a reference to match your input address to a coordinate. There are three street reference data options:

Publicly available sources like US Census TIGER, Local/National government addressing data.

A commercial street dataset such as those from HERE and TomTom.

A street datasetassembled through contributions by the vendor’s own user community (e.g. Google).

Each of these sources has pros and cons related to accuracy. How do you determine which is right for you?

This table shows the pros and cons of each data source.

Cascade Matching

The next aspect of accuracy and precision is about software and the ability to leverage data at multiple layers of precision.

The most highly accurate and precise geocode you can return is at the address point or rooftop and delivery point location. The benefit of a geocoding solution using a commercial dataset is that you get access to multiple levels of precision to match, including address points.

Another benefit is that software vendors who typically leverage commercial datasets also allow users to match at different levels of precision. Results are highly accurate. This feature is called cascade matching. For example, if the user submits an incomplete address without the building number, the software will recognize it. Instead of returning an unreliable, inaccurate match at address point, the software will cascade down to a street name centroid match that is more reliable and accurate.

This diagram shows the different levels of geographic precision. Geocoding software vendors often have logic that allows the input address to match at the higher level of precision first and if a reliable match cannot be found, the query falls back to the next best precision.

Address Point, Delivery Point, and Interpolation

With commercial street datasets, there are usually two points that are returned as part of an address match:

Address point (display x, display y), or Display Point, which is used for centering the map around the location and for other high location accuracy use cases. These point locations are often centered on the rooftop or the parcel centroid.

Road Adjusted point (x, y), or Routing Point, which is used for routing and network analyses use cases.

Both of these points provide highly accurate matches and cannot be obtained using TIGER or crowd-sourced data in a consistent fashion.

In addition to highly accurate and precise matches, commercial street datasets also provide Street Address Range data including street centerlines with range information. The software uses this to interpolate or approximate the match location along a ranged street segment. While less accurate than the Address Point matches, it delivers high location accuracy (within 10 to 50 meters) to meet most use cases in the market.

This diagram shows an input address, ‘240 A Street’ on a street range of 200-299, and shows the Address Point (Display Point) Match, Range Interpolated Match, and Routing Point Match. Often, the distance between the Range Interpolated point and the Routing point is within 10 to 50 meters.

Match Quality Indicators

A good geocoding solution also outputs the match accuracy and confidence on the precision of that match along with the matched coordinate. A match without these indicators is often unreliable for analysis or decision making. A good solution should indicate:

Match status: Whether the input yielded candidate matches to a coordinate in the database or if there are multiple, tied candidates at the same level of precision requiring user review, or if the input was unmatched.

For those records that are matched or tied, a Confidence score or Match score will assess the confidence on the precision of a match.

Accuracy of the match: Whether it was down to address point, interpolated point, street centroid, postal centroid, or city centroid.

This is a geocode output table after running a series of addresses through the Esri World Geocoding capability. The Match_addr, Score, and Addr_type are appended to the input address fields. Additional fields are also appended such as the Match Status, but not shown in this consolidated view.

Geocoding location accuracy depends on many factors. Hopefully, by asking the questions outlined here, you will be able to choose a solution that best supports your use cases, analysis, and downstream decision making. Esri considers and incorporates such aspects into building its own Esri World Geocoding capabilities and products to support the work of users across the globe in all industries. To learn more about geocoding, please refer to our previous blog or visit our webpage.

]]>https://blogs.esri.com/esri/arcgis/2017/10/10/geocoding-delivering-high-location-accuracy/feed/0Speed up your JavaScript development with autocastinghttps://blogs.esri.com/esri/arcgis/2017/10/04/speed-up-your-javascript-development-with-autocasting/
https://blogs.esri.com/esri/arcgis/2017/10/04/speed-up-your-javascript-development-with-autocasting/#commentsWed, 04 Oct 2017 15:00:30 +0000Raluca Nicolahttps://blogs.esri.com/esri/arcgis/?p=87403Continue reading →]]>In the 4.5 release of the ArcGIS API for JavaScript, autocasting support was expanded to all renderers, symbols, and symbol layers. This means that symbols and renderers can be created programmatically without importing their modules. All you need to do is create a simple object, specify the symbol type, and set the desired properties; then the API will autocast the object to its proper class. The samples in the API documentation were updated to consistently follow this new pattern, which cleans up the lists of required modules quite nicely.

Let’s look at an example where we set a renderer with a 3D symbol, labels, and callouts on a FeatureLayer:

To achieve this prior to 4.5 we needed to import six modules for the renderer, symbol, symbol layer, label symbol, text symbol layer, and the callout. The full list of required module imports looks like this:

When specifying object types is required

For many properties, you don’t need to specify the type of object to autocast since the API already knows the expected type. For example, you don’t need to set a type property in an object representing SimpleMarkerSymbol.outline because the expected type for the outline of a simple marker (and all other symbols) is SimpleLineSymbol.

However, renderer, symbol, symbol layer, and geometry objects are usually passed as values to polymorphic properties, meaning the API doesn’t know how to autocast the object unless the type is explicitly specified. The snippet below demonstrates both scenarios in context:

layer.renderer = {
// type must be specified since // 1 of 3 renderer types could be applied here
type: "simple",
symbol: {
// the type must also be specified for symbol properties of a renderer// since 1 of 10 symbol types could be used
type: "simple-marker",
outline: {
// Specifying type for outlines is not necessary // since `simple-line` is the only expected type
style: "dash-dot",
color: [ 255, 128, 45 ]
}
}
};

So how do you know the value of the type property for any given scenario? There are number of ways to find the required type value. You can…

Use the Symbol Playground to configure the code and copy the autocastable snippet for immediate use in your app, or

Infer the value.

Generally, you can infer the type by removing the generic text from the desired class name and kebabifying it. For example, SimpleFillSymbol.type is simple-fill (note that symbol is removed because it is used in all related 2D symbol class names). Another example: UniqueValueRenderer.type is unique-value (there’s no need to specify renderer in the type). IconSymbol3DLayer.type is icon (the Symbol3DLayer bit is common among all symbol layers). See the comprehensive tables below to more fully understand this pattern. Once you’re familiar with it, you won’t have to look it up in the documentation!

We’d love to hear what you think of this change or any other suggestions related to coding workflows.

Happy coding!The ArcGIS API for JavaScript team

Class type tables

Renderer class name

Type

ClassBreaksRenderer

class-breaks

SimpleRenderer

simple

UniqueValueRenderer

unique-value

PointCloudRGBRenderer

point-cloud-rgb

PointCloudClassBreaksRenderer

point-cloud-class-breaks

PointCloudUniqueValueRenderer

point-cloud-unique-value

PointCloudStretchRenderer

point-cloud-stretch

2D Symbol class name

Type

PictureMarkerSymbol

picture-marker

PictureFillSymbol

picture-fill

SimpleFillSymbol

simple-fill

SimpleLineSymbol

simple-line

SimpleMarkerSymbol

simple-marker

TextSymbol

text

3D Symbol/symbol layer class name

Type

LineCallout3D

line

ExtrudeSymbol3DLayer

extrude

FillSymbol3DLayer

fill

IconSymbol3DLayer

icon

LabelSymbol3D

label-3d

LineSymbol3D

line-3d

LineSymbol3DLayer

line

MeshSymbol3D

mesh-3d

ObjectSymbol3DLayer

object

PathSymbol3DLayer

path

PointSymbol3D

point-3d

PolygonSymbol3D

polygon-3d

TextSymbol3DLayer

text

WebStyleSymbol

web-style

Geometry class name

Type

Multipoint

multipoint

Point

point

Polygon

fill

Polyline

polyline

]]>https://blogs.esri.com/esri/arcgis/2017/10/04/speed-up-your-javascript-development-with-autocasting/feed/0Customize your Geocoding experience with Locator Viewshttps://blogs.esri.com/esri/arcgis/2017/10/02/customize-your-geocoding-experience-with-locator-views/
https://blogs.esri.com/esri/arcgis/2017/10/02/customize-your-geocoding-experience-with-locator-views/#commentsMon, 02 Oct 2017 21:30:02 +0000patel_nickhttps://blogs.esri.com/esri/arcgis/?p=87636Continue reading →]]>Esri has many users in many different industries using ArcGIS Online, and has always supported users with the ability to locate or geocode their postal addresses and Points of Interest (POIs). However, users are often geocoding locations that are only of interest to them. For instance, a user in the aviation industry might only need to search Airports based on the 3-letter code (e.g. ‘LAX’) or in full textual form (e.g. ‘Los Angeles International Airport’).

Did you know that with the September 2017 ArcGIS Online update, you can now customize your GeoSearch and Geocoding experience to return search results that are relevant to you?

Locator views allow you to configure a view of the Esri World Geocoding service that only returns specific types of locations or only within a specific country or area. Views can be configured for your organization and used by any apps that support GeoSearch, such as Map Viewer, Configurable apps, ArcGIS Explorer, and so on. Additionally, views can also be used for Batch Geocoding.

Prior to releasing the Locator Views capability, users might get false-positive (unreliable) results or incorrect candidates that weren’t exactly matching to their category of interest (e.g. Airports only). On the other hand, some users required geocoding only at the highest location accuracy (e.g. Address level) and didn’t want results at the postal or city level. The Locator Views capability that we recently released as part of ArcGIS Online this September aims to solve these challenges by limiting the search to the Point of Interest category or precision in the geographic extent that the user requires. This helps reduce incorrect results and focuses the search on the area, POI category, and precision of interest to deliver reliable results. Let us walk you through that in 5 easy steps on how this works through a case scenario.

Assume I’m a user in the aviation industry interested in locating just Airports in the USA.

Step 1 – Create a Locator View

Navigate to your My Content Tab, and create a new “Locator (view)” Item. Fill in the relevant details for the locator view that you want to create to filter your geocoding.

Step 2 – Define the Locator View

Configure your Locator View to search for only specific types of locations within the area you’re interested in using the settings page for the Locator View item you just created.

You can protect the Locator View item from accidentally being deleted.

Next, you can define the types of locations you want to find, whether it is 1) Addresses, Postal Codes, or Populated Places, 2) Coordinates (e.g. MGRS, USNG), or 3) Places of Interest (e.g. Education, Food, Airport). A complete listing of supported categories and coordinates are provided in the documentation: http://arcg.is/2wigsR3. In this scenario, I will select ‘Airport’ for our Locator View.

Within Settings page, you can define where you want to search for the location type you’ve selected. You can select Anywhere in the World, limited to Select Countries, or define a specific area of interest based on a rectangular extent that you define. I will select the country mode and choose ‘United States’.

Finally, click the save button to update the Locator View item with the settings you’ve selected.

Step 3 – Share the item with your organization

Proceed to the Overview page of the Locator View item and click on the Share button on the right side of the page. You can share this view with your organization.

Next, you can select whether you’d like to share access to the locator with your organization only or share with public. Keep in mind that anonymous users won’t be able to access the organization’s shared locators so if you’re concerned about the locator being used by anonymous users, you can restrict the locator’s use to only within your organization.

Step 4 – Configure it for use

Once it is shared, have your administrator go to the Organization tab, and select Edit Settings, and under the Utility Services menu. The admin can add the USA Airport Locator view that you’ve created.

In this step, the administrator can also limit this locator for GeoSearch only or configure it to allow both, GeoSearch and Batch Geocoding. This is especially important for administrators that want to limit the batch geocoding operation as it consumes service credits, while the GeoSearch does not consume any.

Keep in mind that with batch geocoding, the same service credit rates apply regardless of whether you are batch geocoding through the locator views or through the Online World Geocoding service.

You can adjust the search tree by putting the Locator View on top of the Esri World Geocoder or after it. The benefit of putting it before the Esri World Geocoder is that your search requests will locate to airports first and then through the Esri World Geocoder.

Step 5 – Begin using it!

Your new locator view is all set up. Open the map viewer and select the drop down button in the search pane to bring up the locators you want to search against. You can select the newly created Locator View, “USA Airport Locator” to limit your searches to USA airports.

Also, it is worth pointing out that once the admin configures your newly created locator view in the utility service settings, the locator is available for use in any ArcGIS application that uses the organization’s locators configured in the utility services settings. For example, a user using ArcGIS Maps for Office will be able to geocode against the locator view you’ve created to geocode their airport codes in Excel.

Happy airport searching! Try searching for ‘LAX’ and an international airport such as ‘CDG’ and you’ll notice that only airports in the USA are found with the Locator View you created.

For a link to the full documentation on this feature or for the listing of supported categories, please visit http://arcg.is/2wigsR3

We hope you find this capability useful in your work!

- ArcGIS Online & Geocoding team

]]>https://blogs.esri.com/esri/arcgis/2017/10/02/customize-your-geocoding-experience-with-locator-views/feed/3FeatureLayer rendering: taking advantage of WebGL in 2Dhttps://blogs.esri.com/esri/arcgis/2017/09/29/featurelayer-taking-advantage-of-webgl-2d/
https://blogs.esri.com/esri/arcgis/2017/09/29/featurelayer-taking-advantage-of-webgl-2d/#commentsFri, 29 Sep 2017 18:10:08 +0000Kristian Ekeneshttps://blogs.esri.com/esri/arcgis/?p=87111Continue reading →]]>The 4.5 version of the ArcGIS API for JavaScript allows users to opt in to rendering FeatureLayer with WebGL (beta) in 2D MapViews. This is a major step in improving the overall performance of FeatureLayer, providing you with the ability to display more data in the view and rapidly update their visualization. For example, the WebGL-enabled FeatureLayer in the image below displays a layer containing more than one million polygons and updates the layer’s renderer at 60 frames per second as the user moves a slider.

WebGL (Web Graphics Library) is a JavaScript API that uses the graphics card (GPU) of your computer to display 2D or 3D graphics. WebGL is already used to render data in 3D SceneViews. The 4.5 release of the ArcGIS API for JavaScript brings the same capabilities of fast GPU rendering and interactive updates to FeatureLayer in 2D MapViews.

Developing with WebGL to display 2D content offers greater control over how and when features are drawn on the screen, as opposed to a more general purpose drawing technology like Scalable Vector Graphics (SVG), which is what we currently use to render FeatureLayer in 2D. WebGL allows us to optimize the code to quickly redraw every feature on the screen when size, color, opacity, or rotation visual variables change in a renderer.

WebGL isn’t new to 2D drawing in the ArcGIS API for JavaScript. We already use it to render VectorTileLayer in MapView. So why bother using it for FeatureLayer? Vector tiles are great for displaying basemap layers and even thematic visualizations of large datasets because of their performance benefits. However, vector tiles are a static, precooked view of the data. In contrast, FeatureLayer has a wealth of dynamic capabilities, including editing, querying/filtering, and support for on-the-fly rendering and projecting. The FeatureLayer achieves this by working directly with the Feature Service, which can return data based on the needs of the layer. Overhauling FeatureLayer with a similar implementation as VectorTileLayer allows us to provide the user with the dynamic capabilities of FeatureLayer while taking advantage of the following benefits offered by WebGL:

Faster rendering

WebGL paves the way for improved user experiences when changing the visualization of features. This is particularly apparent in apps that provide users with UI controls that alter a layer’s renderer for data exploration or style authoring purposes. Check out the sample below, which displays 180,000 voting precinct locations. The user can move the slider to explore precincts that reported similar margins of victory for each candidate. Despite the large amount of data displayed, the visualization updates smoothly and rapidly.

Additionally, FeatureLayers rendered with WebGL support highlight, which automatically appears when users click or tap features to view the popup. You can also call the highlight() method on the FeatureLayerView to highlight features in other workflows, such as for displaying query/selection results and highlighting features on pointer-move events.

More data can be displayed in the view

The current 2D implementation of FeatureLayer renders graphics with SVG, which limits the the number of features that can be displayed in the view. Now that all modern browsers support WebGL, we can optimize the drawing pipeline so you can display hundreds of thousands, even millions, of features in the browser. This prompted us to make improvements to our methodology for fetching features, and raise the limit of the number of features that we can draw in the view.

The ArcGIS API for JavaScript already leverages feature tile queries to fetch features in a predictable way. This involves dividing the view into square tiles and spatially querying features by the extent of each tile. Because these requests are predictable, we can cache each tile in the browser, ArcGIS Online, and the CDN, effectively minimizing heavy lifting by the feature service. This improves overall querying performance by leveraging one of these caches when possible rather than querying the data directly.

In version 4.5 we query significantly more features via progressive feature tile subdivisions. For example, if the response to a single feature tile request contains more features than allowed in the maxRecordCount of the service, then that tile is subdivided into four smaller feature tiles whose extents will be used to query for more features. Feature tiles will progressively subdivide until the number of features returned for the extent of each tile is fewer than the maxRecordCount. Some features may not be returned because of limits to the number of subdivisions created per tile. We will continue to experiment with those limits so a reasonable number of features are returned. The animation below demonstrates how feature tiles subdivide when fetching features from a service containing more than 180,000 polygon records.

You will notice tiles subdivide based on the location of features. Areas where smaller tiles are present indicate locations that have a higher density of features. Since this dataset represents voting precinct boundaries, it makes sense that the locations of smaller tiles correlate with the locations of large cities, which have more precincts than rural areas.

Enable WebGL for FeatureLayer

To enable rendering FeatureLayer in WebGL at 4.5, paste the following script in your application prior to loading the ArcGIS API for JavaScript in your web app:

This new technology is currently only available when visualizing feature services hosted on ArcGIS Online. Support for client-side feature collections and non-hosted enterprise feature services will be supported at a later release.

Conclusion

The WebGL implementation of FeatureLayer is currently in beta. We plan on improving the speed, quality and responsiveness of the drawing process in a future release. We are actively working on using the API’s web workers framework to offload the massaging of feature tiles to a separate process. When the beta implementation reaches the same level of support as the current implementation, WebGL will become the default for rendering FeatureLayer in MapView.

Keep in mind the following limitations for rendering 2D FeatureLayers with WebGL at 4.5:

Support is limited to layers created from feature services hosted on ArcGIS Online. Non-hosted enterprise feature services and client-side feature collections will be supported in a future release.

Executing query methods on the FeatureLayerView is not supported.

Locations with a very high density of features at large scales may not display all available features at small scales.

Very large datasets may require potentially long initial load times, particularly at small scales. Server-side and client-side feature tile caching allow features to load much faster after the initial data download. More research and development will be invested in improving the efficiency of load times.

Happy coding!The ArcGIS API for JavaScript team

]]>https://blogs.esri.com/esri/arcgis/2017/09/29/featurelayer-taking-advantage-of-webgl-2d/feed/3ArcGIS API for JavaScript versions 4.5 and 3.22 releasedhttps://blogs.esri.com/esri/arcgis/2017/09/29/arcgis-api-for-javascript-version-4-5-released/
https://blogs.esri.com/esri/arcgis/2017/09/29/arcgis-api-for-javascript-version-4-5-released/#commentsFri, 29 Sep 2017 17:40:43 +0000Kristian Ekeneshttps://blogs.esri.com/esri/arcgis/?p=86946Continue reading →]]>Version 4.5 of the ArcGIS API for JavaScript adds some key capabilities and several smaller (but sweet) enhancements that will come in handy. Here are the highlights in 4.5 (as well as 3.22); a full overview detailing new features can be found in the release notes.

FeatureLayer will be rendered with WebGL by default in a future release.

Drawing: it’s here!

You now can enable drawing in your 4.x apps. In this initial release of sketching tools, you can sketch new geometries in a 2D map. Full support for drawing and editing will become available incrementally in future releases, which will include the following:

Editing existing geometries

Creating and editing new geometries including (but not limited to) multipoint geometries.

Sketching/editing widgets

Support for drawing in a 3D Scene

Full editing support, including the ability to enable common geometry validation rules, such as preventing self intersecting lines.

Check out this new sketching sample and play around with the current capabilities.

OGC enhancements

WMS and WMTS layers can now be visualized in a 3D scene. Also, KML support has been added for 2D maps. Support for KML in 3D scenes will be available in a future release.

New options for vertical placement of 3D objects

The vertical placement of buildings and other 3D Objects can be set using a field value, z-value, or an expression. An example of when this would be useful is when placing objects that are either below ground or are flying above ground.

Clustering with version 3.22

If your map has a layer with a large number of points, configuring point clustering makes it easier to visually extract information from your data. When you enable clustering, point features within a certain distance are grouped into one symbol. You can enable clustering in your JavaScript app using either of the following methods:

Clustering is currently only available in version 3.22, but will be added to 4.x in early 2018. This blog discusses how clustering enables data exploration.

There’s more…

Explore the release notes and new samples to learn about more updates such as support for vertical coordinate systems, pop-up improvements, and time-saving enhancements such as expanded autocasting support.

]]>https://blogs.esri.com/esri/arcgis/2017/09/29/arcgis-api-for-javascript-version-4-5-released/feed/0Explore Climate Trends with the Water Balance Apphttps://blogs.esri.com/esri/arcgis/2017/09/25/explore-climate-trends-with-the-water-balance-app/
https://blogs.esri.com/esri/arcgis/2017/09/25/explore-climate-trends-with-the-water-balance-app/#commentsMon, 25 Sep 2017 22:47:58 +0000Daniel Siegelhttps://blogs.esri.com/esri/arcgis/?p=87192Continue reading →]]>Most discussion of climate change has focused on temperature or sea level rise, but changes in freshwater availability will be an even larger challenge in many regions of the world. This topic is often ignored because it is difficult to quantify and forecast, but as hydrologic patterns begin to change we must take notice and adapt. Where you live, is rainfall becoming scarcer? Or more intense? Is the trend different in winter than in the summer? These are the kind of questions we need to be able to answer as we adapt our infrastructure to a changing climate.

Luckily, NASA maintains a record of this information through its Global Land Data Assimilation System (GLDAS), which is available to ArcGIS users through the Living Atlas of the World. This climate record covers the last 17 years (January 2000 to present), and is updated each month as new data becomes available.

GLDAS data in the Living Atlas

Five variables from GLDAS are available as image services through Esri’s Living Atlas: precipitation, runoff, evapotranspiration, soil moisture, and snowpack. Together, these are the forces that drive the terrestrial water budget. Soil moisture plus snowpack is the water storage at any given place. Every month that storage volume changes according to the water flux – recharge occurs when precipitation is high, depletion occurs when evapotranspiration and runoff are higher. So, if you want to know how much rain a specific watershed received last summer, how much of that rain became runoff, and how this affected the region’s water availability, these GLDAS image services make it easy for you to do that analysis.

Today Esri is releasing a new app that makes it even easier to interrogate and explore these data and isolate patterns that could affect your life. Click anywhere on the map to see how a chosen variable has changed over time, and click anywhere on the graph to switch the map to that month of interest.

The water balance panel (on the left) shows how much recharge or depletion occurred during your chosen month, and how this compares to what’s normal. The trend analyzer panel (on the right) shows how your chosen variable was different in the same month during other years. This panel also allows you to see the seasonal variation during a normal year (by graphing the average for each month) or aggregate the time series into annual time steps to see the long term trend more clearly.

This app is based on data from GLDAS version 2.1, which uses weather observations like temperature, humidity, and rainfall to run the Noah land surface model. This model estimates how much of the rain becomes runoff, how much evaporates, and how much infiltrates into the soil. Because the model is run with 0.25 degree spatial resolution (~30 km), these data should only be used for regional analysis. A specific farm or other small area might experience very different conditions than the region around it, especially because human influences like irrigation are not included.

This app can also be seen as a useful template for sharing other climate datasets. If you would like to customize it for your own organization, or use it as a starting point for your own scientific application, the source code is available on github for anyone to use. Please share any remixes you build in the comments bellow so others can see what you’ve done!

]]>https://blogs.esri.com/esri/arcgis/2017/09/25/explore-climate-trends-with-the-water-balance-app/feed/0Disruptive Technology Featured at TechCrunch Disrupt SF 2017https://blogs.esri.com/esri/arcgis/2017/09/25/techcrunchdisruptsf2017/
https://blogs.esri.com/esri/arcgis/2017/09/25/techcrunchdisruptsf2017/#commentsMon, 25 Sep 2017 18:22:10 +0000Katie Deckerhttps://blogs.esri.com/esri/arcgis/?p=87124Continue reading →]]>Esri recently attended TechCrunch Disrupt in San Francisco, September 16-17th, 2017. The conference brings together entrepreneurs and next-generation products from across industries and the globe. Before the Disrupt conference started Esri, 750+ developers and a variety of other sponsors gathered for a weekend hackathon.

The goal was to spark innovation via teamwork and competition. Esri provided over 100 hacking teams with our free ArcGIS Developer Subscriptions and credits to catalyze ideas involving maps, authoritative data, imagery, visualization and analysis tools, and more. Developers could use our APIs and SDKs across mobile, web, and desktop to turn these ideas into apps (or at least prototypes, time was tight). In addition, we offered a $5,000 valued prize of cash and software for the best use of Esri technology.

Esri Apps at TCDisrupt SF 2017

There were many exciting results and, in response to recent natural disasters, many ideas focused on aiding disaster relief efforts. This lead to inventive apps with core location components, from drone imagery feature detection to SMS help-request services. That said, our winner “took a different route” and focused on immersive visualizations of driving routes for new drivers. Congratulations to our winner RouteBud! Find out more about them and other prize winners that used Esri below.

RouteBud – Esri Prize Winner

RouteBud is an Android and Unity app built by two high school women, one a senior the other a junior. As new drivers, these women wanted to better understand how to get from point A to B and the safety implications of their route. Using Esri’s routing API and Arity’s collision data API, they were able to generate a route and assess the risk of that route. They then displayed this information in both an Android app using Esri’s ArcGIS Runtime SDK and in a Unity 3d scene with graphics exported from Esri City Engine. With the important contextual information and immersive visualizations, app users can choose the route that, “is best for them based on their personal preferences.”

Again, congratulations to Route Bud for the win! We’d also like to give a shout out to Ground Zero.

Ground Zero – Accenture Prize Winner

Ground Zero is a “full-fledged platform” for disaster relief. The team built a series of innovative, interconnected tools to help streamline and improve relief efforts. They created machine vision algorithms for drones to detect people and an SMS chat bot for victims then combined the outputs of these services onto an Esri map-based dashboard for first responders. And, this was all built on a decentralized block-chain-like ledger to reduce bottleneck request failures on a server. With all these modern (and complex) technologies, the team explains “First responders will always have the information they need in times of disaster.”

To find out more on the hackathon apps view DevPost or check out this TechCrunch article on disaster relief apps from the hackathon. We’ll be joining developers and tech innovators at the upcoming TechCrunch Disrupt Berlin in December, we hope to see you there too!

You can also join Esri for our Esri Developer Summit Europe, October 24-26th in Berlin, Germany where we’ll show you how to build cutting-edge apps using advanced mapping technology from Esri. At DevSummit you will be the first to see new tools for geo-enabling your apps to get pro tips from the developers who made them.