Include 2525C Symbol ID Code in Export Tags where applicable about joint-military-symbology-xml

[abouffard]

Added to PlanBox backlog.

[csmoore]

Not sure what the time frame is - but I would like this done by the next time we regenerate the styles.

There is a table here which might assist importing the legacy codes into the data model:
https://github.com/csmoore/military-symbols-dotnet/blob/master/MilitarySymbols/Data/LegacyMappingTableCtoD.csv

[csmoore]

@abouffard - plz make sure this (& #95 ) gets added to the current sprint - I am going to add these 2525C tags manually to the stylx for now.

As a reminder, a large percent (60-75%?) of the 2525D entity entries should map to 2525C and have a 2525C tag.

[abouffard]

Done in #121

[csmoore]

Visually verifying this, looks good, Just visually spot checking a few of the ones marked retired, I noticed this entry looks like might be an error:

O*OPU----- OPOPU---------- 98 100000 00 00 (should map to 40 110105 00 00 ?)

But to completely verify this, I'll check that output table mostly matches the input table provided (or maybe that is what I am already looking at in that table? I'm not completely sure how it is generated)

So I just wanted to confirm there were no updates to the source data since I created it (i.e. that you don't have a fixed version of that table so I am starting with the latest version),

[csmoore]

OK I see this explanation now: https://github.com/Esri/joint-military-symbology-xml/tree/master/samples#legacy-support.

This looks/sounds good, I think the only improvement I can suggest (that would help me & anyone viewing this table out also) is to add a column(or columns) with the 2525D name (Symbol set : Entity : EntityType : EntitySubType)

& then this will look like/be functionally equivalent to the original data/xls provided (so we can hopefully get to one configuration controlled list/table)

[csmoore]

So this is almost good to go: to close this out (as mentioned in #108 (comment)) - let's just make the following changes/refinements while this is fresh in everyone's mind:

1. Change the tag order to
   `{2525C tag - optional - only for entities (not for modifier/amplifiers)},IconType,Geometry,Name,ID
2. For the new 2525D entities change the tags to "2525D_NEW" or "NEW_AT_2525D"
3. Add columns to the sample dataset output to add 2525D name (Symbol set : Entity : EntityType : EntitySubType)

With these refinements, I think this will be a really useful capability/output/dataset

[abouffard]

Thanks Chris. I just want to clarify a few things on your list.

1 and 2 above are describing changes to the image file name category tag exports, and 3 above is describing a change to the legacy support export, correct?

Regarding 1 above, I added the SIDC_IS_NA tag value to the amplifiers, frames, and modifiers because I assumed we needed the tags for everything to have a consistent number of parsable (semicolon separated) values, as suggested here...

"Speaking of this IconType enumeration: MAIN, FULL_OCTAGON, FULL FRAME, etc. - there should always be an entry for this for when we need to parse these tags - so need to add an enumeration for MOD1, MOD2 (Modifier 1 & 2) - and any other icons that are missing this enumeration (this is a lower priority item, just mentioning with the icon change above in case related)" - from #108

Since the Military-All-Icons.csv file contains ALL the icons, is it not necessary that there be place holder values in the tags for frames, amplifiers, and modifiers, where entities would normally have a 2525C SIDC or "NEW_AT_2525D"?

SIDC_IS_NA was meant to mean that a 2525C SIDC for an item is not applicable (for one of several reasons).

No problem either way. Just want to clearly understand the requirements.

[csmoore]

Right 1,2 affect/change the icon exports & 3 the legacy table.

I think further down in that same thread there was a smallish comment about possibly making the 2525C one optional & it is a change/something to remove now that I see how that added some unuseful tags to the modifier/amplifier entries. So if & when we parse these we won't try and parse/grab the :-5 tag for those types & that should hopefully keep the tags a little cleaner for those entries.

Leaving open the possibility to deterministicly parse the tags is still a useful goal, but it always a tradeoff & we don't want to unnecessarily pollute the tags if we don't have to.

[abouffard]

#123 reflects suggested changes 1, 2, and 3 above.

[csmoore]

Looks good so far, I'll give this a closer test/verify tomorrow AM.

Just on a visual inspection the legacy table looks good though. For the icon files, now that I notice those "*"'s in the 2525C SIDCs, I do worry they might have some side effects on queries (but we can address that if/when an issues arises)

[csmoore]

I just started testing this, I thought I'd run the test app & clicked on the 2nd value ("SFPPV-----") and it now says its invalid (instead of retired) - so I just wanted to make sure that was the intended/desired behavior.

It also looks like if I use a "*" (instead of "-") in the wildcard fields in the test app 2525C symbol id or MakeSymbol call it doesn't work (maybe this should be changed so it just ignores those string fields that don't matter).

UPDATE: just created new issue #124 for this one/question

[abouffard]

Thanks for catching, Chris. That legacy information got lost when the raw comparison data was imported. Now fixed in #125.

[csmoore]

OK, I gave this data a good test/diff against the original dataset from August (after ignoring the substitutes, repeats from that table) & the only difference I noticed was:

Yours:
EFOPDD---- EFOPDD--------- 98 100000 00 00
Mine:
E_OPDD---- E_OPDD----***** 40 150100 00 00

Which look like a correction to my data so this data looks good to me (or as much as I am able to spot&brute force test anyway) - nice job