search

Esri / military-features-data

Source data for Esri defense and intelligence feature templates. This data is used to create features and derived data products using military symbology.
Apache License 2.0
46 stars 32 forks source link

APP6B issue in 1.x.1 Space Track and 1.X.2 Air Track #73

Closed caporossi closed 6 years ago

caporossi commented 9 years ago

We are reviewing all the symbols represented dall'App6B and I would like to present in this repository the various issue that we find.

The tests were carried out with:

The families of symbols as grouped in the same Hierarchy find in APP-06 (B) Joint Symbology.pdf

Description Hierarchy Sym-id Correct Symbol Wrong Symbol Note
MEDEVAC 1.X.2.1.1.9 SFA-MFO-------- The symbol appears higher than the other
ELECTRONIC SURVEILLANCE MEASURES 1.X.2.1.1.10.2 SFAPMFRZ------- The symbol appears higher than the other
ANTI SURFACE WARFARE/ASUW 1.X.2.1.1.11.1 SFAPMFPN------- The symbol appears higher than the other
AIR TO SURFACE MISSILE (ASM) 1.X.2.2.1.2.1 SFAPWMAS------- The symbol appears higher than the other
AIR TO AIR MISSILE (AAM) 1.X.2.2.1.2.2 SFAPWMAA------- The symbol appears lower than the other

geomessage for test

1x2family

csmoore commented 9 years ago

Thanks for the information - feel free to add to/edit this issue.

An important note: the updates/fixes are being done in the next version of the standard 2525D/APP6C (which combine the 2 standards - and I have not seen this issue there). However 2525D won't be available in Runtime until the next release.

@abouffard - this does raise the issue if we have a way to convert an App6B SIDC to 2525D/APP6C? Is that something that would need added?

abouffard commented 9 years ago

@csmoore , we do not currently have a way to convert APP-6(B) to 2525D/APP-6(C), just as we don't have a way to convert 2525B (in any of its variants).

We have an issue on the JMSML repo to add these backward compatibility capabilities to our data, so it is on the to-do list. The question is prioritizing this against other tasks on our list.

caporossi commented 9 years ago

@csmoore Thanks for the information 1) We are currently setting up several tables, similar to the previous one, for all the APP-6(B) symbol families (1.x.3 , 1.x4, 1.x4, 1.x5, 2.x.1, 2.x.2, 2.x.3), some of them contain a lot of symbols with rendering problems, putting all these tables in this issue would make it long and unreadable, so I'd rather open a single issue per family. Let me know how to proceed.

2) From what you wrote, I understand that all updates/fixes will be implemented in the next version of the standard (2525D/APP-6C)!!! For better understanding, I can tell that the availability of a APP-6(C) rendering engine is useful, but unfortunately all the systems I know so far (Land, Air, maritime, Incident, ecc..) send tracks in APP-6(A) or APP6-B format!!!! Of course I mean systems sending tracks in real time. I know about no system using or sending tracks in APP6C format.

csmoore commented 9 years ago

One issue per major section/area will be fine - I was just hoping to avoid too many new, or fine-grained, issues (something like <= 10)

On doing the fixes, changes in the next standard version - that is a legitimate, important issue for the fielded legacy systems that will need addressed (hopefully by the standards committee since the only openly available, licensed dataset, with the fixes, is the 2525D version).

csmoore commented 9 years ago

Assigned support ID: BUG-000087786

csmoore commented 6 years ago

I can confirm that this is still an issue with the latest stylx (red dot denotes center point). Some air are centered on top some on bottom of dot - probably just needs to be made consistent (make whatever is used most common):

image

Adding dev tag and re-estimating. Additional note - this should be verified in Pro or on map showing symbol center points to be able to see non-centered symbols.

lfunkhouser commented 6 years ago

@dfoll @ACueva @topowright Please read all comments in this issue, understand the issue, and identify the remaining work that needs to be completed.

BobBooth commented 6 years ago

Checked in Pro 2.2 to see which Air symbols were offset. Determined that there were four that needed fixing. SFAPMFRZ------ SFAPMFPN------ SFAPWMAS------ SFAPMFO Offset Y axis of symbol by 18% for each. image

BobBooth commented 6 years ago

Applied -2% offset to Air to Air missile symbol. image SFAPWMAA

BobBooth commented 6 years ago

@csmoore - updated Medevac rotary wing symbol that was showing up too large. image

BobBooth commented 6 years ago

I think with that last change, this issue is done. Removing the Dev tag. Still needs verified.

BobBooth commented 6 years ago

image Issue_73_test_data.zip Images and test script to generate them with the runtime app.

ACueva commented 6 years ago

APP6B Standard 2018-03-26_8-27-26 Verified SFAPMFO--------in Pro 2.2 Daily Build 11859 2018-03-26_8-22-42

APP6B Standard 2018-03-26_9-30-44 Verified SFAPMFRZ------- in Pro 2.2 Daily Build 11859 2018-03-26_9-29-58

APP6B Standard 2018-03-26_9-34-05 Verified SFAPMFPN------- in Pro 2.2 Daily Build 11859 2018-03-26_9-33-47

APP6B Standard 2018-03-26_9-39-55 Verified SFAPWMAS------- in Pro 2.2 Daily Build 11859 2018-03-26_9-42-16

APP6B Standard 2018-03-26_9-44-10 Verified SFAPWMAA------- in Pro 2.2 Daily Build 11859 2018-03-26_9-43-44

Runtime 100.2 Output 2018-03-26_8-32-19 2018-03-26_8-33-08

ACueva commented 6 years ago

In addition to verifying the symbols draw in Pro 2.2 and Runtime 100.2, the symbols align properly in relation to other symbols. 2018-03-26_9-55-09

ACueva commented 6 years ago

@topowright I've manually tested these items. 2 labels are still present. QC- Verify (Automated) and QC-Verify (Checklist). I am not sure if these are applicable.

If they are not, this issue can be moved to Done.