How to properly Display Minimum Safe Distance Zone in Pro 1.2

[Dbarnes1]

Minimum Safe Distance Zone (SIDC 272100) is a complex symbol and will probably require a unique solution compared to the other area symbols for 2525D. Here is how it looks in the standard:

Here is how it currently renders in Pro:

[csmoore]

For now (as a shorter-term workaround), can you just add a "uniquedesignation" label to the right & we can manually create each ring.

So your workaround version of this symbol will look like below (if "uniquedesignation"="1")

[csmoore]

@Dbarnes1 - can you implement this suggested workaround with the current set of stylx fixes?

[ottenw]

FYI - at SSMC 2015-1, CP15-009 "Correction to Minimum Safe Distance Control Measure Symbol" was approved. It removed ring #3. Not sure when you plan to implement SSMC approved post 2525D publication changes.

[csmoore]

Thanks for the info, good to know this change is coming before we exert too much effort into this exact symbol. The CP I found was "15-029-AR Correction to Minimum Safe Distance Control Measure Symbol"

One related note: This symbol also could use a bit of clarification in the point ordering to update/clarify "Center Point" to "Point 1 (Center Point)" and the other points are "Point 2" (Ring 1 radius) and "Point 3" (Ring 2 radius) - I believe this is the only symbol with that point order ambiguity. ( @abouffard @joebayles )

[Dbarnes1]

@csmoore I was able to put in a unique designation label rule, but it automatically places the label at the center of the polygon. I'm not sure if this is an issue, because it appears as if the "Center Point" of the symbol is where there can be a unique designation according to your point ordering comment above?

Here is the updated symbol with unique designation in the test dataset (ControlMeasuresAll) project:

[ottenw]

@csmoore @Dbarnes1 The center Point is always just that - the center point. The distance between the center point and PT 1 is the radius of the inner ring and the distance between the center point and PT 2 is the radius of the outer ring. The numeric "1" and "2" are part of the inner and out ring and should always be present; they are not amplifiers or modifiers. @abouffard and @joebayles do you feel a CP is needed to clarify the draw rules WRT center point and PT 1 and PT 2?

[csmoore]

The display rules are fine for humans, this issue/ambiguity arises when we try to use this point ordering for a geometry or a message and we don't know if center point should be encoded as point 0 or point n (last) - unless there is other guidance somewhere else for encoding this symbol as a geometry/message.

Like mentioned I believe this is the only symbol depiction that doesn't explicitly use "Point 1, Point 2...Point N" where this is an issue, so hopefully it is an exceptional case.

[Dbarnes1]

Update: I've moved the unique designation to as close to the perimeter of the feature geometry as I can using Maplex. While this is a short term solution, I want to figure out a way to actually get the unique designation to overlay on top of the line.

[joebayles]

@ottenw I think we absolutely need clarification here. Please feel free to weigh in.

To reiterate the intent behind this symbol, this is a CBRN symbol that annotates Minimum Safe Distance from the source location of an NBC event (read point or area). However, it will only be concentric circles from a fixed point. I will write some issues in JMSML to deconflict that, but in the interim, we need to figure out how to render this correctly per the current standard.

@Dbarnes1 and I figured out how to render the concentric circles, but how are the radii for circles 1 and 2 communicated?

@Dbarnes1 feel free to include a screenshot of what the latest version of this symbol looks like.

[ottenw]

@joebayles - I'll draft a CP to clarify draw rules

[csmoore]

Just to further clarify, this is the only recommended change I had (based on the original 2525D.0 symbol shown in the original issue description above):

[Dbarnes1]

This is the latest way to render this symbol in Pro, thanks to @joebayles suggestion. Still only a short term solution

[csmoore]

Dan showed me the workaround & it looks pretty good/flexible.

Since you took another approach to what I was thinking you should just be able to hard code the "1 2 3" into the label rule and not use the "uniquedesignation" field I had originally suggested (unless you think this label will need to change)

[joebayles]

Except for the third ring, this is perfect.

[csmoore]

@joebayles - please remember we are implementing the released 2525D (2525D-0.0) not the CPs (2525D-0.3 in this case?) and to try to provide guidance in accordance with the 2525D as published for now (but we do appreciate knowing what is coming - we just need to make those changes in an agreed-upon, controlled way).

[csmoore]

Closing this as a known issue-with workaround for now