Image Discrepancies

[joebayles]

Frame Symbol Issues

File	Context	Dimension	Identity	Issue
0601	Reality	Air	Hostile	Symbol should not be closed at bottom
0605	Reality	Space	Hostile	Symbol should not be closed at bottom
0635	Reality	SubSurface	Hostile	Symbol should not be closed at bottom
2601	Simulation	Air	Hostile	Symbol should not be closed at bottom
2605	Simulation	Space	Hostile	Symbol should not be closed at bottom
2635	Simulation	SubSurface	Hostile	Symbol should not be closed at bottom

Entity Symbol Issues

File	Symbol Set	Entity	EntityType	EntitySubType	Issue
01110111	Air	Military	Fixed-Wing	Reconnaissance	Should not have blue reference octagon
05121000	Space	Civilian	Space Station		The ring should be thicker
10130101	Land Unit	Fires	Air Defense	Main Gun	The arc should not close on Friendly version
10130102	Land Unit	Fires	Air Defense	Missile	The arc should not close on Friendly version
10130102	Land Unit	Fires	Air Defense	Missile	Should not have Main Gun symbol
10130200	Land Unit	Fires	Naval Gun Liaison		Anchor flukes should be shorter
10163300	Land Unit	Sustainment	Seaport		Anchor flukes should be shorter
15130000	Land Equip	Engineer Vehicles			The top of the E is too long
15220300	Land Equip	Sensors	Radar		The bolt is crooked
15230000	Land Equip	Manual Track			Code in MIL-STD may be wrong
20111500	Land Installation	Military	Nuclear		Center circle should be larger
20111600	Land Installation	Military	Printed Media		Should not be 20116000.svg
20120902	Land Installation	Infrastructure	Postal	Post Office	Did not draw completely
20121309	Land Installation	Infrastructure	Transportation	Seaport	Anchor flukes too long
20121310	Land Installation	Infrastructure	Transportation	Shipyard	Anchor flukes too long
25130300	Control Measures	Command and Control Points	Checkpoint		"AMN" should be "CKP"
30130204	Sea Surface	Military	Noncombatant	Launch	Should be spelled YFT
35150000	Sea Subsurface	Fused Track			Should not be closed on top (should be open)
36140000	Mine Warfare	MILCO			Should not have a symbol
36140100	Mine Warfare	MILCO	General		Should have a symbol
40130100	Activities	Operation	Patrolling		The "P" is too small
40130201	Activities	Operation	MISO	TV & Radio	Files should use "_", not "."
40131202	Activities	Operation	Emergency Food Distribution		Files should use "_", not "."
40131400	Activities	Operation	Firefighting Operation		Should be Icon Type:Main version of the Maltese Cross (40131402 is the Full Octagon version)
45161505	Atmospheric	Weather	Fog	Obscured	Should not be named 45161605
45161506	Atmospheric	Weather	Fog	Freezing, Sky Vis	Should not be named 45161606
46130203	Oceanic	Oceanography	Beach Slope	Moderate	Should have light gray dots
46130204	Oceanic	Oceanography	Beach Slope	Steep	Should have dark gray dots
50110100	SIGINT	Signal Intercept	Communications		Should not be named 50110000
50110200	SIGINT	Signal Intercept	Jammer		Should not be named 50110100
51110100	SIGINT	Signal Intercept	Communications		Should not be named 51110000
51110100	SIGINT	Signal Intercept	Communications		Should not be named 51110000
51110200	SIGINT	Signal Intercept	Jammer		Should not be named 51110100
52110100	SIGINT	Signal Intercept	Communications		Should not be named 52110000
52110200	SIGINT	Signal Intercept	Jammer		Should not be named 52110100
53110100	SIGINT	Signal Intercept	Communications		Should not be named 53110000
53110200	SIGINT	Signal Intercept	Jammer		Should not be named 53110100
54110100	SIGINT	Signal Intercept	Communications		Should not be named 54110000
54110200	SIGINT	Signal Intercept	Jammer		Should not be named 54110100

Modifier Symbol Issues

File	Symbol Set	Modifier	Sector	Issue
10501	Land Unit	Radar	1	The bolt is crooked
10132	Land Unit	EPLRS	2	The end points should be level
11231	Land Civilian	Other	1	The symbol should say OTH, not CIV
54061	SIGINT	Air Traffic Control	1	Should not exist

[joebayles]

MIL-STD-2525D does not currently capture the remarks that are in MIL-STD-2525C regarding US-specific organizations and limiting their use to the "Friendly" Frame. Organizations are listed below:

40131501 - ATF 40131504 - DEA 40131505 - DOJ 40131506 - FBI 40131509 - USSS 40131510 - TSA 40131512 - US Marshals

[abouffard]

Regarding multiple SVG files, I have multiple attributes in the XML to handle this situation - different svg files. So for those like 40110303 that have multiple files, don't use the Graphic attribute. Instead, use four shape specific graphic attributes...

CloverGraphic="40110303_0.svg" RectangleGraphic="40110303_1.svg" SquareGraphic="40110303_2.svg" DiamondGraphic="40110303_3.svg"

I designed it to be flexible enough to support CircleGraphic and CurveGraphic if purists think there should be custom shapes that fit those frame types better. I don't expect our software to take advantage of these options, necessarily, but believe the standard is best served by having those options.

I'll consult with Chris and Lorraine to see how they want the CSV export of this information to be portrayed.

[abouffard]

I'm checking with DISA regarding the range of agencies you mention above. I suspect those restrictions are not needed in 2525D.

[csmoore]

Regarding 40110303, I'm not sure what the exact issue is (since at a glance I don't see anything in the standard, esp. Table G-III that would indicate needing 4 different symbols for this)

What I can understand is that: Entity: SymbolSet=40, Name: Activities : Incident : IED Event : IED Cache, Point Maps to 4 different (yet almost identical / similar) center icons : 40110303_0.svg 40110303_1.svg , 40110303_2.svg 40110303_3.svg I have no idea what "CloverGraphic" would even mean in reference to center entity icons - why would these not all be the same.- esp. given that everything uses the same "reference octagon" to place this icon.

Unless I am missing something (& until I understand better): Lets say the better solution would be to CR the SVG/standard to try to resolve/eliminate any special rules needed to find an icon (or fix the icon to apply for all frames- this business logic should be very straight forward - if not that needs to be addressed/simplified

For the simplified CSV name/entiry/icon tables - 2 cases:

1. if <10 cases - pick the icon that matches the most frame cases for that entity and just use that
2. if this is indeed a valid common issue (> 10 special cases/entities) - just create 4 rows for these special cases and append something (e.g. "_0" "_1"?) to the name - just so the approach is uniform

Additional Note: it is probably time to create some high-level doc for this schema, I'll add an issue for this. For something like this "Clover Graphic" thing I would expect to be able to link to something in this repo like code or markdown description that explains something like this - too much explanation & doc seems to be going into these review comments, when stuff like that should be added to the doc as it arises.

[abouffard]

It's ok if you don't understand the implementation of the standard in the XML. Just as its been made clear to me that I don't need to understand the details of the process to take its CSV output and build StyleX and feature class coded domains.

Here is where I could go into a long explanation of the logic I've used in designing the XML, but I won't because I get the sense it really doesn't matter to providing CSV output you can use.

Suffice it to say that IED cache point icon is not a centered entity icon. Its just one of many full frame icons out there that don't respect the boundaries of the octagon, and therefore have four variations. The XML can account for those four variations and two more, if needed in the future.

[csmoore]

...or... we could make a Change Request to make them centered icons to simplify the logic for everyone...I hope that a possibility for something like this particular icon - we don't need to be complicating the symbol set just so some centered icon has a line that touches the frame - this icon should be perfectly fine: "Underlined IED" - adding requirements to touch frames doesn't add a lot of practical value & has real costs in terms of implementation

[abouffard]

Yes we could, but there are several of these kinds of icons sprinkled throughout the standard (the infantry symbol being one of the most common). Icons are either full frame, full octagon, or main sector octagon. Lots of discussions at SSMC and JSP meetings have taken place about these. It all is based on taught military doctrine (the tradition of using an X that touches the frame) and we just have to account for these special situations. The horizontal line isn't just an underline, its the same line used to help illustrate the various supply caches/dumps/units in the land unit symbol set.

[csmoore]

OK I see - definitely worthwhile for those very few and select icons that have a lot of history like Infantry (a symbol dating back to the Roman empire) - they should be trying to avoid these special cases for new icons - like IED that presumably most folks are not going to care if it touches the frame - so I think a CR is still valid for those newly developed ones

[joebayles]

Regarding Full Frame symbols: I don’t think any of us is qualified to weigh in on the standard. If the standard is a line across the bottom of the symbol, then that is what we should implement. It seems to me that @abouffard already designed the XML to accommodate this.

Regarding the Clover Graphic: Here it is, along with the other 3 affiliation graphics, for those that aren't familiar with MIL-STD-2525: (Incidentally, this is also the reason we have 4 different variations of Full Frame symbols).

Regarding a curated, complete list/table: That's the plan. @jrweakland will be capturing his list here as well, although I think I may move the list to a... cleaner issue.

[csmoore]

On the full frames, I don't think I was saying you should never do that, just that the instances should probably have been minimized & only used where they added value. In the 2 of examples cited: Infantry & Target, they do add value, in the underlined IED one (and probably more) the value added is probably not all that great.

But once we see more (or any) of these drawing, I might feel differently - either way I do stand corrected that it probably doesn't rise to the level of a CR against the standard. I do think that maybe a generic icon XXXXX.svg (i.e. without the "_0, _1, etc.") could be provided for those folks who don't care about the logic of the center icons touching the frames.

But for everyone - do feel free to question how something is done & its usability - the first major revision of anything is bound to have some kinks and areas that need improvement - so we do want to try to improve things where it is valid and where we can.

[joebayles]

For the IED symbol, it's not an underline. It's a graphic modifier denoting a cache of IEDs, which is different than an IED event. Here's an excerpt from MIL-STD-2525D:

In most instances, there is a generic icon: In this instance, the generic icon for an IED Event is 110300, and if you want to denote a cache, you add the Full Frame line that has been used for a cache in 2525 for some time (see screenshot from 2525C below for the Supply, or Cache symbol). The symbol than becomes 110303, and depending on the affiliation (to choose the proper frame and therefore the proper version of the full frame symbol), it becomes 110303-x. My assumption about your example of the IED symbol above is that you used the Unknown affiliation variation of the symbol on the Friendly affiliation frame.

Now, I do think that requesting a single naming convention for those files (_0, .1, etc.) is a reasonable request so we can begin coding the schema appropriately, and we should maintain a list of issues with these images to return to the standards committee as suggested corrections.

[csmoore]

Many thanks for the explanations - & sounds like we still do have a CR to make some of those names more consistent (& sorry I sidetracked - all of this makes a bit more sense now) & yes, probably a new issue would be helpful now that we have somewhat diluted the intent of this one.

I think a lot of these implementation issues will become more apparent once we get out of the "data-modeling/thinking-about" stage and get to the "draw/use the data" stage.

We will indeed implement this when it shows up in the export data & it is properly tagged for use. So this discussion was very good in that it let us know that in our "image file-name-category-tags" export product that we do need

1. To make sure there is an entry for each icon (& you probably already thought of this)
2. More importantly a consistent way to tag these 4 frame-icon's for use

(& maybe I'll record a new issue for this so these details get tracked) - thanks again for all of the good/thorough explanation

[jrweakland]

@abouffard

I have noticed that the font used in the SVGs does not match the font used in the 2525D draft standard. This causes numerous errors in the SVGs when letters are used. You can see this in the "EntitySubType ID="INTEL_COLLECTOR" Label="Intelligence Collector" Graphic="Appendices/SeaSurface/30130104.svg"" image above

csmoore note added: here is the sample as I see it output/drawn with "Arial" font:

[csmoore]

NOTE: (for all) on capturing a symbol's name/id uniquely - Because of the highly nested nature of the XML in this repo, it is unfortunately not enough to copy/paste the XML line to easily locate/identify that symbol - e.g. for the symbol @jrweakland mentions, if would be better to identify with something like this:

Sea Surface : Military Non Combatant : Auxiliary Ship : Intelligence (Symbol Set: 30, Code 130104)

(Symbol Set : Entity : Entity Type : Entity SubType) - this is most important when the names are repeated/non-unique, but a good practice for easily finding things in general

[csmoore]

For the fonts issue, this is actually somewhat complex - but this should be recorded as a defect/CR against the standard (the standard should not be using a "special", "non-standard font")

The problem is that there are only a few select fonts that are truly cross platform & non-proprietary & therefore guaranteed to be installed on a system - so the fonts used in the SVGs (and shown in the standard should be limited to those fonts.

In short, if the standard remains unchanged, then they are requiring implementors to install those exact, proprietary fonts on any system that uses it - in order to fix a defect like @jrweakland reports.

I believe the only place that the draft version of the standard addresses fonts was in the Amplifier(Labels) section which states: "All text shall be presented in upper case sans serif font" NOTE: I believe this requirement for all labels to be uppercase should also be changed in the standard. (this is new to 2525D & could have some unintended consequences)

[csmoore]

One more important note on these drawing/font-type errors - they are somewhat dependent on

1. the viewer used (each has its own quirks - IMHO I have observed that Google Chrome seems to draw SVG best) (Important Note: the fact that those "purple/hidden reference lines are showing up, might mean you are not using the best viewer)
2. the availability of those fonts/family on a given machine

So for instance with the library I use ( https://github.com/vvvv/SVG ) & the output/drawn with "Arial" font:

[joebayles]

Font issues - This is something that @abouffard should bring up to the standards committee immediately.

Capturing the truly unique symbol in this deficiency list - I've already incorporated @jrweakland's list into my own at the top of the thread. I think the font issue is persistent throughout the symbols, so I'd hesitate to continue capturing that ad nauseum.

[csmoore]

@abouffard please review/write/submit this Change Request (CR) (note: open another issue here if you think we need a separate discussion/tracking ticket on this):

Global Sample Image (&SVG) CR: "Because of the Intellectual Property and cross-platform implications * of using specific fonts in the images shown in the standard (which are produced by an associated set of SVGs) - these fonts (and the sample images & SVGs that use/portray them) should be changed to add a generic "san-serif" font family. As currently shown/implemented, these images can not be produced accurately on non-proprietary systems. Of important note is the "Bold" font versions should be removed from the images/svg's, these too are proprietary.

Example:

<text id="XXX" font-family="'Arial'" font-size="85">XXX</text>

Should be (so it includes the non-proprietary option):

Option 1:
<text id="XXX" font-family="Arial, sans-serif" font-size="85">XXX</text>
-or-
Option 2:
<text id="XXX" font-family="sans-serif" font-size="85">XXX</text>

Note 1: the removal of the single quotes: '  
Note 2: Option 1 list allows those systems that have Arial installed to use it, & those without to fall back on the alternate
Note 3: this format worked for me in Chrome, but you might want to verify elsewhere & on a system that does not have Arial installed)

* For more information on the Legal Considerations of Fonts see: https://fedoraproject.org/wiki/Legal_considerations_for_fonts

[mepler]

As the technical adviser representative for the SSMC and the one initially creating the SVG files, I would like to make the following comments pertaining to the comments in this string. I am using Adobe Illustrator CS6 on a Windows platform and understand that some OS, especially Linux, doesn't install by default the Arial font. After some testing, the above 'Option 2' should be able to work, but requires a batch text change in the SVG files after the graphic has been completed, since you must choose a specific font within Illustrator. As long as this change is generic enough that ALL those using the SVG files can read them without make a second change to each image, then we can make this batch change prior to release of the SVG files. The images within the standard are for visual reference (ie the purpose of the blue bounding octagon) and the SVG images that will be provided upon release of the standard are to be used for implementation.

[abouffard]

I'm going to work with Mike to have him add the SVG files to this repo, under the Apache V2 license. Once they are all "fixed" he can, as he indicates above, do a batch replace of the "Arial" font.

[csmoore]

@mepler - thanks much for the info - I always forget what a pain it is to deal with Fonts cross platform - indeed I didn't even know that "Arial" was a proprietary one (although web developers have to deal with these pains all the time & I thought Arial was considered a "safe" one for them - I guess not on Linux)

Note: it was my bad on the purple lines thing above - I thought those screenshots had come from another SVG viewer product (why I was questioning), not the standard (it indeed makes sense to have these reference lines there)

[joebayles]

At the risk of resurrecting the font lawyers...

@mepler - I know we've got a solid answer for font issues in the symbols, but I thought I might mention that a batch change to Arial will not work for Hydrography/Bottom Features/Bottom Characteristics.

[csmoore]

@mepler RE: "Symbols that require Serif; Italic Fonts (that is the issue @joebayles points out above)

For any of those those symbols that specifically require Bold or Italic font styles, instead you would need to replace the specific font mentioned in the font-family with this code:

font-family="serif" style="font-style: italic;" font-family="serif" style="font-weight: bold;" font-family="serif" style="font-style: italic;font-weight: bold;"

Ex. a symbol like Oceanographic : Hydrography : Bottom Features : Bottom Characteristics - Sand;(46, 120601) won't display the Italic S without that particular font TimesNewRomanPS-ItalicMT installed (& most won't have this installed). All of this assumes that the symbols can't just all use "san-serif" font - but if there does need to be exceptions, the above should provide a platform independent implementation. HIH

[csmoore]

Are any of the symbols listed in the original issue ready to be rechecked? Can we get them rechecked (esp. since this issue is now > 3 months old)?

I'd like to close this one and start a new issue with the current set of open SVG issues so I can start adding the new issues I am finding.

[abouffard]

@joebayles , since you originated this issue, would you have time to review the original symbols to see if they are fixed now? We should at least add something to the backlog in PlanBox so we can pick this up soon. Also, @mepler , have you any input on the original issues and their status?

[mepler]

I am taking a look at the issues now and will let you know my findings/results.

[mepler]

After looking at the list and comparing them with the master symbols, I believe these have already been addressed. Please let me know if they are not on your side.

[csmoore]

OK, we'll assign this to @joebayles to verify & autoclose if not verified in a week.

Just spot checking the above - I noticed a few still open but I'll add these to the new/next/current issue so we can close this old one:

25130300 : Should be "CKP" (instead of "AMN")

10130101 Left line obscured by frame:

46130204 : Should Have Grey dots

[joebayles]

Everything from the original table was fixed except for these five.

File	Symbol Set	Entity	EntityType	EntitySubType	Issue
20120902	Land Installation	Infrastructure	Postal	Post Office	Did not draw completely
25130300	Control Measures	Command and Control Points	Checkpoint		"AMN" should be "CKP"

[csmoore]

Many thanks for checking/verifying & I'll move the Post Office one to the new issue #98

Just a quick question on the LandEquipment(15) Manual Track (240000) one - this one seems correct to me - standard and filename both show as 15240000. Just let me know if I got this one wrong & I can re-add to new issue.

[joebayles]

Adjusted the table... Thanks for checking.