Define Reference Grid From Area should have labeling for output features

[mfunk]

Currently the output from Define Reference Grid From Area is symbology only, and does not include labels for the MGRS/USNG grids.

Expected Behavior

It would be nice to have labels for the MGRS/USNG grid squares based on the input grid size. The GZD field has the values, but there is no logic to the labeling to turn them on or off for specific map scale ranges, meaning if we turn them on, the will always be on. Since we have 6 different grid sizes (from GZD down to 10m) there should be different label scales for each. However that isn't possible right now with the current tool output as there is only one feature class. Also, if ALLOW_LARGE_GRIDS is selected and the user has a grid with a LOT of cells, the labeling will bog down the map redraw.

Current Behavior

Possible Solution

Method 1: Add fields to track the input grid size and use that to set up label classes which we might (I think) be able to define different scale ranges.

Method 2: Custom Python to update the output LYR with the correct scale ranges (if possible) based on the input selections.

Other methods: ?

Steps to Reproduce (for bugs)

N/A

Context

Following the MGRS output from the widget this is more of an equivalency problem, than bug or enhancement.

Your Environment

• Version used: 10.3.1
• Environment name and version (e.g. Chrome 39, node.js 5.4):
• Operating System and version (desktop or mobile): Windows 10
• Link to your project:

[BobBooth]

@mfunk - if we used Method 1, we could probably also output a set of LYR/LYRX files in a group layer using arcpy.mp with definition queries on the cell size, and set scale visibility ranges and labeling on those (http://pro.arcgis.com/en/pro-app/arcpy/mapping/layer-class.htm). Then the visibility of the labels would be controlled by the visibility of the layer within the group layer, which would be controlled by the display scale.

[adgiles]

@lfunkhouser @topowright @dfoll @ACueva

PE's,

Can we have some more detail on what you want to achieve from this issue?

If it is just a case of having the labels turned on in the lyr file, then any PE should be to create a new layer file.

I personally don't think we need to get bogged down with the fact that a user could create a grid with a lot of cells and it would take a while to label, as the main use for a GRG would be over a limited area, with a relatively small amount of cells (tens/hundreds not thousands).

[topowright-zz]

I agree with @adgiles on this one. We have not got this feedback from any users and the capability to label any cell this way can be done by just using the len() function for label properties. I feel like this should close and if it becomes an issue in the future we can address it then.

[topowright-zz]

I have removed this from the known issues for April release and added it to the issues addressed for April 2018 @dfoll @ACueva please verify

[lfunkhouser]

@topowright was the issue "addressed" or is it a "non-issue"? If it is still behaving as designed, then this should be closed with "as designed" or a workflow added to the documentation to do what @adgiles commented. This should be removed from known issues, but not added to issues addressed if it was not "fixed".

[topowright-zz]

This can be staisfied by building a lyr file for ArcMap and ArcGIS Pro that would show labels of the grid based on the scale. The idea is at a small scale would show GZD and the large scale map would show a most precise version of the grid.

[BobBooth]

@topowright - I'm not sure how much sense multiple scale ranges from grid labeling are, if the tool is only creating cells of a given size. So, for example, if you make 10,000 m grid cells, the "GRID" field gets values for that level, like "15SUD71". If you zoom out to a scale that makes those labels too big for the cells, you could drop the last couple of digits, but then you would have a whole lot of cells with the same "15SUD" label. The tool only outputs features for the specified level.
We could make the tool output a set of feature classes, one for each scale level (at least, for the smaller scale levels), an have corresponding layers in a group layer with scale dependency and their own labels set. Not sure if this is needed, though.

[lfunkhouser]

Clear requirements are needed to move forward on this issue.