Latest Contributions by megan_r

Dictionary styles provide a highly customizable way to visualize attribute-rich data in your maps and applications. With a look-up table of individual symbol parts, a dictionary script connecting attribute values to symbol keys, and a configuration file for fine tuning, these styles can be used together with the Dictionary Renderer to build complex symbols driven by multiple attributes in your data. I created a dictionary style for the Alternative Fuel Stations layer in Living Atlas that provides information about each station at a quick glance.   In this blog, I will share some of my top tips for creating your own custom dictionary style while we take a closer look at the one I created. If you want to explore the style as you read, here are links to the style and a web map where a layer has already been configured with the style.  Tip 1 – Gather resources to use while building your style Whenever I start building a new dictionary style, I am prepared with my favorite resources at hand. First is this blog by my colleague Thad: Create custom dictionary styles for ArcGIS. The blog shares all the tools and steps needed to build your style from start to finish. My go-to tools are:  DB Browser for SQLite,   Visual Studio Code,   ArcGIS Pro, and   A subset of the data to test the style along the way.  The Custom Dictionary Style Guide is another great place to get started with in-depth, step-by-step instructions for creating your own custom style. I also like to have the dictionary renderer toolkit handy. The toolkit is full of resources for understanding, creating, and troubleshooting dictionary styles, as well as a few sample styles worth exploring.  Tip 2 – Don't forget about built-in default symbol keys Each individual symbol part has a unique key defined in the look-up table. The best way to create and edit these symbol parts is in ArcGIS Pro. First add the style to your project Catalog then double-click the Alternative Fuel Stations style to open the table. Here you will find all the symbol parts in the style.   Let’s focus on the Fuel Type symbols first. There are 7 fuel type symbols and one default symbol (we will get to that one in a moment), each with their own unique key. With exception of the default key, these keys follow the format “fuel-” followed by the fuel type abbreviation found in the Fuel_Type  field.   The dictionary script is an Arcade script that contains instructions on how to use attribute values to build symbol keys. The dictionary script uses $feature.Fuel_Type to produce the fuel type key. This is the first key listed, so when a feature is evaluated, the type key is the first one returned.   But what happens when Fuel_Type is empty or the full name, “Electric” is used instead of “ELEC”? In these hypothetical cases, the script would return “fuel-” and “fuel-Electric”, two keys that do not exist in the look-up table. This is where the default symbol comes in!  Dictionary renderers have built-in default symbol keys that are used when the first key returned in the script doesn’t exist in the look-up table. All you have to do is add a symbol with following key: “Invalid_P” for points, “Invalid_L” for lines, or “Invalid_A” for polygons.  Tip 3 – Vary symbol property values with primitive overrides  In this style, the outline of the symbol is used to communicate two different pieces of information about the fuel station. If the outline is a solid line, the information has been verified, but if it is a dashed line, the information has not been verified. The color of the outline stroke indicates the operating status of the station: available, planned, temporarily unavailable, or unknown. There are 8 combinations of possible outlines: Instead of requiring individual symbol parts for every combination, the style uses primitive overrides to drive the color of just two symbol parts: the solid verified outline and the dashed unverified outline.   A primitive override is a way to change a symbol property value, such as the outline color, differently per feature. Parts of a symbol can be tagged with a primitive name, which is used by the script to apply overrides to the parts that have been tagged with the specified name.    In the dictionary script, the status of the station specifies the color used in the override, poColor. The syntax for a primitive override is po:<primitive_name>|<property_name>|<value>. For this style this means that when drawing the verification symbol, for any part of the symbol tagged with status-color, the Color is replaced with the value of poColor:   Now to tag the symbol parts with the primitive name. This override will be applied to stroke of the verified and unverified symbols in the look-up table. From the look-up table, select the Verified symbol and navigate to the Layer Properties tab. From here use the element drop down to drill down to the Shape Fill symbol, then format that symbol to get down to the fill and stroke properties. In the structure tab, click the little tag symbol next to the stroke and specify status-color as the primitive name. Now repeat for the unverified symbol.   With the symbol elements tagged, the style now supports all 8 possible outline combinations of verification statuses and operating statuses using just two individual symbol parts.   Tip 4 – Take advantage of configuration properties   Now if you are familiar with the Alternative Fuel Stations Living Atlas layer you may be thinking, “wait a minute- there is no ‘verified’ field in that data!” You caught me. I am using a subset that I modified, adding the ‘verified’ field which will come in handy for a future blog. This style works with the verified field, but maybe you are using the Living Atlas layer and don’t have that field in your data. That's why I created a configuration property that allows you to include or ignore the verification field.   The configuration file is a JSON object where you can define additional configuration options that alter how symbols draw. This style has multiple configuration options, but we’ll start with the use_Verified_Field configuration. Here I specified the name of the configuration, the default value, possible values, and a brief description. I also included the Verified field as a symbol field leveraged by the dictionary script. You can really see this come to life in ArcGIS Pro:  When the use_Verified_Field configuration is on, the dictionary script will use the value in the verified field to return a key for a solid or dashed line. When it is off, the dictionary script will return a key for the solid line for all features. To leverage the value of a configuration property in the dictionary script, use the syntax $config.name or in this case, $config.use_Verified_Field: Now anyone using this style to symbolize a layer can control if the verified field is used.  Tip 5 – Know when to use a symbol field or text field for labels  That last configuration property was about how symbol parts are calculated using a symbology field in the data, but now let’s look at a property to turn labels on and off. In the layer, EV charging stations include information about the network they belong to in the EV_Network field. If a station doesn’t belong to a network, that field is populated with “Non-networked.”   First, add a new symbol for the label to the look-up table then make sure it is a shape text symbol in the layer properties tab. To use the EV network in the data, replace the text string with the field name in brackets, in this case, [EV_Network]:  In the configuration file, I created the show_EV_Network property so that you can turn the labels on and off. I also specified the EV_Network field as a symbol field. Why not a text field you ask?  Text fields work great when you want to label all features. If I had chosen to use a text field, every feature would be labeled with their EV_Network value and EV stations that aren’t networked would have a “Non-networked” label. I decided I only wanted networked EV stations to be labeled, so made that a condition in the dictionary script:   Text fields cannot be accessed by the dictionary script, which means that they can’t be used as variables in the logic. Since the script needs to use the EV_Network value to determine whether to return the label key, I included the EV_Network field as a symbol field in configuration file.   Tip 6 – Use unique primitive names  The final configuration property in this style is the show_Connector_Type property which allows you to show or hide a banner that displays all the available connector types at an EV charging station. The available connectors are listed in a single field in the Alternative Fuel Stations layer. While the configuration is a simple on/off property like the others, this portion of the dictionary script is a bit more complicated as we have to consider which connector symbols are used, how those symbols are positioned, and how wide the banner needs to be to accommodate that many symbols:  Let’s begin with the banner width. The look-up table contains symbol parts for banners that will fit 1, 2, 3, or 4 connector symbols. In the dictionary script, we create an array of the available connector types and count the number of objects in the array to determine which banner to use.   Then the connector symbol keys are returned. The script uses a for loop to iterate through each object in the array, returning the key for each corresponding connector type symbol part. If we stopped here, all the connector symbols would draw on top of each other. Luckily, we can use primitive overrides here!  The X offset override shifts tagged symbol parts along the x axis.  With each iteration of the for loop, 11 points are added to the X offset, so that the following symbol will be 11 points to the right of the previous symbol. In the look-up table, each connector symbol has been tagged with a primitive name that follows the syntax [connector type]_marker (e.g. J1772_marker, CHAdeMO_marker, etc.).   So if a station has two connectors, J1772 and CHAdeMO, the keys would look like this:  Banner key: background-2 Connector type keys: con-J1772;po:J1772_marker|OffsetX|17;` and `con-CHAdeMO;po:CHAdeMO_marker|OffsetX|28; Unlike our previous example with primitive overrides, each symbol part needs to have a unique primitive name because the offset values to be applied to each symbol so that they do not overlap.   Tip 7 – Return keys in drawing order  In the last line of this dictionary script, we return the string of keys, which tells the client what individual symbol parts to use to create the final symbol. The order the keys appear in the string dictates the order in which symbol parts are drawn. When you look at a final symbol drawn with this style, you can see that the connector types draw on top of the banner, and the banner draws under the fuel type symbol and the outline, while accessibility indicator draws on top:   In this dictionary when all the configuration properties are on, the keys are returned in the following order: fuel type, network name, EV banner, EV connector types, verified key, fuel type, and access.  The fuel type key is returned twice because the built-in default key (Invalid_P) is used only when the first key returned produces a key not in the look-up table. Adding the fuel type key a second time ensures proper drawing order, but another option is adjusting the symbol parts to remove unnecessary fill symbols that may “bury” symbols.   And that’s it- you now have all my top tips for creating your own custom dictionary style! You can dig into this style further by downloading it here or get started building your own custom style. Let me know in the comments below what ideas you have for creating custom dictionary styles!      ... View more

In ArcGIS, military symbology is supported using the Dictionary Renderer. When configuring data symbolized using military symbology for use in a web application, you need to consider which client application the data will be consumed in. Most ArcGIS web applications and app builders (such as Map Viewer, Dashboards, Instant Apps, and Experience Builder) are built using our more modern JavaScript API 4.x, which includes support for reading web maps which include layers configured with the Dictionary Renderer.  This post will describe the steps you need to know in order to prepare data for use with military symbology in those applications. A few important notes to understand before you get started:   Web AppBuilder, ArcGIS Dashboards (Classic), and Map Viewer (Classic) are all built using a different version of the JavaScript API (3.x). Because of that, you need to follow some specific steps when configuring the symbology in ArcGIS Pro before publishing. Check out Preparing Data for Use with Military Symbology in Web AppBuilder for that workflow.  Currently, the Map Viewer does not include the ability to configure a layer in a map with the Dictionary Renderer. For now, in order to configure layers with the Dictionary Renderer for use in web applications, you can either:   Follow the steps below to use ArcGIS Pro to configure the Dictionary Renderer on layers prior to publishing as a web layer, or    Use the JavaScript API 4.x in a custom app to easily configure the Dictionary Renderer directly on the layer. Check out this sample code for guidance. Now back to our regularly scheduled programming.  The quest to leverage a military symbology in your web applications begins in ArcGIS Pro, where you will configure your layer(s) with a Dictionary Renderer. ArcGIS Pro uses desktop styles with Dictionary Renderer by default, so you’ll need to configure your layers to use a web style instead. If you are working in ArcGIS Online, the web styles are already shared there, but if you are working with ArcGIS Enterprise or using a custom style of your own, you will need to publish the web style to your organization first (we show you how to do this below).  Once you have your layers configured with the web style, you are ready to share it as a web map to your portal. Your web applications will use the web style to draw the features in your map with military symbols you configured in ArcGIS Pro.   Now let's break that down a bit.  To complete this workflow, you’ll need:   Data ready to be configured with a dictionary renderer,   A military dictionary web style (which you may need to publish), and  ArcGIS Pro.  If you don’t have data at hand, you can download a project package with sample data here. The three layers in this package (Land Units, Control Measure – Lines, Control Measure – Areas) can be configured to use MIL-STD-2525Bc2. Now let’s get started!  Add your layer to a map in ArcGIS Pro. If you are working with the project package linked above, this step is already complete. In the Symbology pane for the layer, choose Dictionary as the renderer. Configure the layer with a web style as opposed to the desktop styles ArcGIS Pro provides by default. To specify a web style, navigate More > Add custom dictionary… and then follow the appropriate set of steps below:  ArcGIS Online: In the Add a style file window select the style that corresponds to the military symbol standard used in the layer. For use in web applications be sure to choose the latest version. Under Portal select ArcGIS Online. Search box - owner:"styles_esri" type:"Style" to narrow the results down to the military dictionary web styles provided by Esri. ArcGIS Enterprise: You may have to publish a military dictionary desktop style (released with Pro) as a web style if it is not already available. To do so, follow the steps below:  Symbology pane: First choose the symbol standard you want to publish in the Dictionary drop down (if it’s a custom style, you’ll need to first click More > Add custom dictionary… and browse to your custom desktop style).  Then click More > Add dictionary to project. The style should now appear in the Catalog pane.  From the Catalog pane, expand Styles, right-click the military style and select Share as Web Style. This will create a new portal item in Enterprise, which you should now be able to search for and add in the Symbology pane as in Step 3a If you hover over the Dictionary you selected, you should now see a URL indicating you are in fact using a web style (if a desktop style is selected in the drop-down, just the name of the style is displayed when hovering): Configure the Dictionary Renderer by mapping the Symbol and Text Fields that the dictionary is expecting to the fields in your data.   If there is a SIDC field, only that field needs to be mapped as a Symbol field. If there are additional fields in the data that can be used as text amplifiers in the symbol, you can map them as well.  Set configuration properties.  Set scale factor if needed.  Now that your layer is configured with a web style to use the correct symbology, navigate to the Share tab and select Web Map.  Under Select a Configuration, be sure to uncheck Use symbol types compatible with all clients. This ensures the dictionary style symbols will be used, which are compatible with applications built using the JavaScript API 4.x. Voila! Now you can view this web map in the Map Viewer, but WARNING: If you change the symbology properties of the layer in the Map Viewer you cannot go back to configuring the Dictionary Renderer. Other functionality will still work like editing, configuring popups, etc.  You now have a web map that will work in ArcGIS web applications such as Experience Builder, Instant Apps, Dashboards, and so on. If you need to make any further modifications to the Dictionary Renderer settings in the map, you will need to do this in ArcGIS Pro.   ... View more

This article is a follow-up to Preparing Data for Use with Military Symbology in Web AppBuilder. In this article, you will walk through the steps to prepare and share exercise data that has been symbolized with military symbols for editing in Web AppBuilder. This requires publishing both a map image service (to render the military symbols correctly) and a feature service to support dynamic data and editing.  This exercise uses sample data that was created from  the Plan a historic battle with Military Tools for ArcGIS Learn ArcGIS lesson. If you haven’t already done so, I recommend completing this lesson in order to get a better understanding of military symbology and the Military Symbology Editor in ArcGIS Pro. Explore the attribute tables for the layers to see how attribute values correspond to the military symbols displayed on the map using the Dictionary Renderer. Once you have reviewed the lesson, download the exercise data and get started!  Get Started Before preparing the exercise data, it’s important to know that hosted feature layers are not supported for this workflow. Therefore, an enterprise geodatabase registered as a data store in ArcGIS Enterprise portal is required to store your data.  If you don’t have an enterprise geodatabase already, follow these steps to create one. Otherwise, you will just need to connect to an existing enterprise geodatabase. Once you have connected to an enterprise geodatabase, it must be registered with ArcGIS Server as a registered data source.  Downloading the Exercise Data In the Plan a historic battle with Military tools for ArcGISLearn lesson, you create a Military Overlay using the military symbology tools in ArcGIS Pro. The Military Overlay is a series of layers in your geodatabase that includes feature templates for each layer and configures the layers with the specified dictionary renderer. The layers in the exercise data you will be downloading have been symbolized with a single symbol and paired down to the three layers we are interested in, Land Units, Control Measure – Lines, and Control Measure – Areas. A fourth layer (Railroad) that was not created from the Military Overlay is also included in the exercise data.   Download the project package here.  Open and unpack the Project package. Once unpacked, you should see a map containing the following layers: Land Units, Railroad, Control Measure - Lines, and Control Measure - Areas.  At this point, these four layers are stored in a File Geodatabase within your project.  Connect to your enterprise geodatabase. If the database connection does not already exist by navigating to the Catalog Pane > right-clicking Databases > New Database Connection.  Use Feature Class to Feature Class to copy the four layers in the map to your enterprise geodatabase.  Ensure that the Land Units, Railroad, Control Measure - Lines, and Control Measure - Areas, layers created in the previous step have been added to the map.   Verify the source of your layers by right-clicking a layer in the Contents Pane and navigating Properties > Source > Data Type. The data type should be “Enterprise Geodatabase Feature Class.”  Remove the original layers from the map (those with the data type “File Geodatabase Feature Class”). Now you are ready to begin symbolizing the exercise data with military symbols!  Symbolizing with Military Symbols If you haven’t already, explore the attribute tables of the Land Units, Control Measure - Lines, and Control Measure - Areas layers. The attribute value of fields (such as affiliation, status, hqtffd) will be used to drive how each record is symbolized.   Right-click the Land Units layer in the Contents pane and select Symbology to begin configuring the symbology: Primary Symbology: Dictionary Dictionary: MIL-STD-2525Bc2 Map symbol fields and text fields to the dictionary. In this exercise, the fields are mapped automatically.  Accept all remaining default configuration properties.  Repeat the above steps for the Control Measure - Lines and Control Measure - Areas layers. Your map should look like the map below:  After symbolizing your data with military symbols, you may want to create Feature Templates to define categories of items that editors are allowed to add to a feature layer, based on specific combinations of attributes.   Navigate Edit > Features > Manage Templates to open the Manage Templates pane. Follow the instructions here to create feature templates for some of the layers. I elected to create feature templates for a few attribute combinations in the Land Units layer: To configure the feature templates you have created, select the template you want to modify then “Properties.” In the Attributes tab, you can select attributes values in the applicable fields to override the default geodatabase values and apply them to features the template creates:  Preparing the Data Add Global IDs to the Land Units, Control Measure - Lines, and Control Measure - Areas layers. Ungroup any existing group layers, as they are not supported in the Web Feature Layer. In this exercise, all layers are already ungrouped.  Sharing the Data Share the layers in your map as a web layer to your Enterprise Portal with the following configuration:  Choose Map Image and check Feature to enable feature access. This is important so that the web application will be able to properly display the military symbols and allow them to be edited.  Configuration > Feature:  Operations: Enable Editing on the feature layer (check the appropriate option such as Add, update, delete) and optionally choose Export Data or Export Sync.  Properties: Check all boxes (curves, z and m values) as appropriate. Analyze, fix any errors, and publish!  This publishes a map image service and a feature service to your Enterprise Portal.  Add Layers to a Web Map and Create a Web App In a browser, navigate to your Enterprise Portal and open a new map in Map Viewer Classic.  Add the map service to the web map first, then the feature service and the two services will appear as one layer in the map.  Note: After adding the layers to the web map, you should see the Edit button in Map Viewer Classic. If you don’t see the ‘Edit,’ return to Step 2 of Sharing the Data and ensure that editing is enabled on the feature service.  Save the web map and create a Web App in Web AppBuilder:  After saving the map, click Share > Create a Web App > select the Web AppBuilder tab > Get Started after specifying a title and tags for your web app:  At this point, Web AppBuilder will open in your browser tab.   In Web AppBuilder, add the Edit widget to your application from the Widget tab: Select the first empty widget and type “Edit” in the search window that appears. Select the Edit widget to add it to your application.  For this exercise, you can accept the default configuration of the Edit widget. More information about configuring the Edit widget can be found here.  You can now use the Edit widget in your map to add, update, and delete the features you have symbolized with military symbols!  If you created feature templates for your layer in ArcGIS Pro, the templates you created will appear in the Edit widget:  If you did not, default symbols will appear in the widget instead, but you will still be able to add and modify features with military symbols.   More guidance on using edit widget can be found here.  ... View more

When configuring data symbolized using military symbology for use in a web application, there are a few things to consider: The client application will the data will be consumed in, and  Whether that data will be dynamic or involved in editing workflows. Web applications built using the JavaScript API 3.x for ArcGIS include Web AppBuilder, ArcGIS Dashboards (Classic), and Map Viewer Classic. These apps require publishing both a map image service (so that the server can render the military symbols correctly) and a feature service to support dynamic data and editing. We break down that workflow below. Getting Started  Before preparing your data, it’s important to know that hosted feature layers are not supported for this workflow. Therefore, an enterprise geodatabase registered as a data store in ArcGIS Enterprise portal is required to store your data. If you don’t have an enterprise geodatabase already, follow these steps to create one. Otherwise, connect to an existing enterprise geodatabase. Preparing Your Data You will need to create a schema in your Enterprise Geodatabase to store the data and then configure the data as layers in ArcGIS Pro using with the Dictionary Renderer. You can either do this by creating the schema from scratch (if the data will be imported or fed from another system such as GeoEvent Server) and adding layers to the map manually or by using the Military Overlay created with the Military Symbol Editor in ArcGIS Pro to create a Military Overlay (which will automatically create a schema and add layers to a map).  Follow these steps if the data will be imported or fed from another system and will include a Symbol ID code: Create a schema in the Enterprise Geodatabase that includes a field for the symbol ID code plus any additional fields needed to support text amplifiers or other symbol modifiers. Note that the symbol ID code should be a text field with 15 characters if using MIL-STD-2525B, MIL-STD-2525C or APP-6B, or text field with 20 characters If using MIL-STD-2525D or APP-6D. Add the layers to a Map in ArcGIS Pro, and for each layer configure the Dictionary Renderer in the Symbology Pane: Choose the which symbol dictionary to use based on which the military specification you need. If there is a SIDC field, only that field needs to be mapped as a Symbol field. If there are additional fields in the data that can be used as text amplifiers in the symbol, you can map them as well.  Specify any Configuration Properties needed to fine-tune how symbols are rendered on the map. If you need to use a scale factor for the symbols, you can configure a scale factor one under the Advanced Symbology Options tab. You can either specify a constant value or an arcade expression. Follow these steps to create a Military Overlay using the military symbology tools in ArcGIS Pro if you will be adding new features to the map using ArcGIS editing tools. This will create a series of layers in the enterprise geodatabase, including many feature templates for each layer (starter symbols to support editing workflows), and will add the layers to a map and configure them layers with the dictionary renderer. First, enable the Military Symbol Editor in ArcGIS Pro.  When prompted to choose the Military Overlay Database, select the enterprise geodatabase you created earlier. Select any the Military Symbology Standard you need to work with. The tool will add many Feature Templates to layers in the map. These are useful for creating features using the ArcGIS Pro editing tools, but might be too many for the web editing tools. Optionally you can use the Manage Features tool to remove any Feature Templates that won’t be needed by your app users for web editing. Note that at this time, the Military Overlay schema does not include a field for Symbol ID Code, but one can be added manually to the layers. Finally, Be sure to add Global IDs to your dataset in the Enterprise Geodatabase so it can be used for editing. Ungroup any existing group layers in the map, as they are not supported in the Web Feature Layer. Publish your data Share the layers in your map as a web layer to your Enterprise Portal with the following configuration: Choose Map Image and check Feature to enable feature access. Under Configuration > Feature: For Operations: Choose Enable Editing on the feature layer – Add, update, delete For Properties: Check all boxes as appropriate for curves, z and m values Analyze, fix any errors if needed, and then publish! Configure your Web Map The previous step publishes a map image service and a feature service that both must be added to a web map in Map Viewer Classic. Be sure to add the map service to the web map first followed by the feature service, so that the two services will appear as one layer in the map. From there, you will be able to use the edit tools in the Map Viewer Classic and Web AppBuilder to add, modify, and delete features. Or, if data is being fed from GeoEvent Server, you should see the data update automatically and the correct military symbols in ArcGIS Dashboards Classic. Because the symbology of your layers is attribute-driven and configured with a dictionary renderer, as new features are added or updated, the symbols will update to reflect the attribute values for the fields that were mapped to the dictionary renderer during the Preparation step in ArcGIS Pro. Check out this exercise that walks through this workflow using sample data! ... View more