bad JSON exception from Symbol Dictionary Mil2525c

2818
4
12-20-2013 04:35 AM
JeremieJoalland1
Occasional Contributor II
When migrating our project from ArcGIS Runtime 10.1.1 to 10.2, we face new exception messages from ArcGIS using Military Symbology :
--> Unexpected Bad JSON string for Id: SINSTALLF
or
--> Unexpected Bad JSON string for Id: SMO
...

when using SIC code like :
"EFFPK----------", "SFGPEXI---MO---", ...

We are not using MessageProcessor, but we get Military Symbols by code from MIL-STD-2525C Dictionary (same standard than before) with getSymbolImage(), then apply this BufferedImage as PictureMarkerSymbol.

This error messages appear when exiting the application, sometimes during it's execution.
is this a known issue ?
0 Kudos
4 Replies
MarkBaird
Esri Regular Contributor
I'll bring this to the attention of the military team who maintain the symbol dictionary so we can fix it.

Apart from the console output, are you seeing any other issues when getting your buffered image from the symbol dictionary?

I guess I'm also interested why you extract the buffered image from the symbol dictionary and add that as a picture marker graphic?  This isn't the way we indended these graphics to be added to the map.  Your method will work, but the message processor is how we had intended these items to be displayed:

- The purpose of the getSymbolImage method on the symbol dictionary is to make a picker or a swatch
- You will need to do your own labelling if you don't use the message processor
- If you display lots of images which are the same you will use more system resources than if you had chosen to display via the message processor.  We've put lots of effort into optimising the message processor for displaying 1000s of items.
- You won't be able to display anything other than point symbols.  Line and area symbol types will not work using your method.  I think these are what you call your tactical graphics.

If you need any help with using the messge processor then feel free to ask.  We've got a message processor example in our sample application which you can take a look at.

Mark
0 Kudos
CarlosColón-Maldonado
Occasional Contributor III

--> Unexpected Bad JSON string for Id: XXXXXX


I've been getting those since version 1.0 and I've gotten so used to them that I've come to ignore them (see post). And, I'm using the message processor because, as Mark describes it, my app depends on creating both single and multiple point symbols. I believe the console output is a self-inflicted exception generated by the dictionary itself when it cannot determine which image to choose for a given string, probably because it does not contain them, but it does not seem to affect its continuing operation.

I thought of doing exactly what you're doing only for single point symbols because graphic modification of border and fill on military symbols does not exist in the 2525c component, except that my app also rely on labels that the symbol image does not include.
0 Kudos
JeremieJoalland1
Occasional Contributor II
Apart from the console output, are you seeing any other issues when getting your buffered image from the symbol dictionary?


Apart from this messages, all is working fine, with same behavior than version 10.1.1.
But we definitly didn't have theses annoying messages with same SIC... so something has changed. Theses messages appear in console ouput sometines during execution but mainly when exiting JVM.

I guess I'm also interested why you extract the buffered image from the symbol dictionary and add that as a picture marker graphic? This isn't the way we indended these graphics to be added to the map.  Your method will work, but the message processor is how we had intended these items to be displayed:
- The purpose of the getSymbolImage method on the symbol dictionary is to make a picker or a swatch
- You will need to do your own labelling if you don't use the message processor
- If you display lots of images which are the same you will use more system resources than if you had chosen to display via the message processor.  We've put lots of effort into optimising the message processor for displaying 1000s of items.
- You won't be able to display anything other than point symbols. Line and area symbol types will not work using your method.  I think these are what you call your tactical graphics.


Thank you fro providing these arguments in choosing Meassge Processor instead of our current way, it will definitly be discussed with my team leaders... However for now we have a limited use of Military Symbology, onyl for points, we will not use line or aea symbols, neither labels, and in 10.1.1 we wanted to be able to manage different symbol size, which was not possible, as only a scale factor could be changed in json file for all messages. And for now, we don't have performances issues. This explain our choice...

If you need any help with using the messge processor then feel free to ask.  We've got a message processor example in our sample application which you can take a look at.


Thanks, I already played with your samples using message processor, and will not hesitate to come back to you if necessary on this subject.
In the meantime, could you tell me why we are getting these messages in 10.2, is it from bad SIC ? or is it because of Dictionary ? and will it be fixed for next version ?
0 Kudos
MarkBaird
Esri Regular Contributor
The limitation that you pointed out about the symbol scale only changed by hacking a file has been addressed at 10.2

See the item in the release notes:

https://developers.arcgis.com/en/java/info/release-notes.htm#ESRI_SECTION1_2EB05CD8B9D9499CA63277195...

- The MessageGroupLayer class has new functionality to set the symbol scaling, as well as minimum and maximum scales for symbol visibility.

The error message you are seeing is caused by some bad content in the symbol dictionary file.  The error message gives you a clue that we use JSON encoding internally :-).  I have asked for this to be fixed, but can't promise it will be in the next release.

Regarding your approach to displaying the symbology, I don't see that you will experience issues if you are not going to display many items.  The main issue is with adding functionality and application scaling in the future.

Mark
0 Kudos