Range Fans By Feature tool needs inputs that are not packaged with the template

[dfoll]

Range Fans By Feature tool needs inputs that are not packaged with the template

Open the tool, select an input, but nothing that is packaged with the template that can be used as input centers has the appropriate fields for this tool.

[dfoll]

@jrweakland @nfeuerstein

on second thought, this tool does not exist in the https://github.com/Esri/solutions-geoprocessing-toolbox/releases release, maybe the question to ask is if it should be included in future templates

[mfunk]

It existed in the earlier versions of the template. Effectively we've taken the tool away from users.

[nfeuerstein]

@mfunk - the tool is not important, the functionality is. @dfoll Did the tool "Range Fans by Feature" do something unique that the current tools "Range Fans From Weapon Bearing Limits" and "Range Fans from Weapon Parameters" don't address?

[mfunk]

You are correct, the tool provides the functionality. With that in mind all three handle different cases. Weapon Bearing Limit and Weapon Parameters need a separate table from the point locations. By Feature just uses fields from the same input input points.

[nfeuerstein]

@mfunk @dfoll @jrweakland The requirement behind having a table for weapon parameters (because a table can be easily modified by the user) was provided during the DCGS-A initiative. The reasoning behind this was that an M249 (for example) has the same parameters no matter where on the map it is located - so referencing a table with stored weapon parameters for all possible weapon types made more sense than duplicating the parameters as attributes for every M249 in operation. Is there a use case in which the location of the weapons and the weapon parameters must be contained in a single feature class?

[mfunk]

Yes. In the case you are not using anything listed in the table. For example you are mapping the observable area of a camera. Two cases of this came up at the UC, though one guy wanted to visualize it in 3D which is more of a special case for range domes.

[nfeuerstein]

The table is editable. Couldn't you add the camera and its parameters to the table?

[dfoll]

@jrweakland @nfeuerstein @mfunk is right that the three basically duplicate functionality and basically just (in the case of "...from weapon bearing limits" and "...from weapon paramters") offer specialized/streamlined workflows. i don't think there is a case when we would say that locations/parameters must be stored in a separate feature class, but i would be hesitant to go the opposite direction of saying that to use the tool, you MUST have a table for parameters (instead of a feature class with those attributes).

that being said, if we go the route of saying you MUST have a table with weapons parameters, that would mean we can drop the "range fans by feature tool"

[nfeuerstein]

The requirements provided by the DCGS-A SMEs was that the location of the weapon/sensor (perhaps that could be better explained in the doc and the name of the tool could be more inclusive) would be a point feature class, while the parameters/capabilities of the weapon/sensor would be managed in a table. We followed their direction.

@jrweakland Interested in your feedback and thoughts on this. What are the current workflows for mapping weapon systems/sensors, of which the feature class is ultimately used to create range fans based on the system parameters?

[joebayles]

This issue was moved to ArcGIS/solutions-templates#8