Skip to main content

I hope the title is already quite self explanatory.

As an example, consider the following JSON document;

{
    "boolean_1": true,
    "boolean_2": false
}

When this is being read with a JSON reader, it returns the following output;

0684Q00000ArDXkQAN.png

I would prefer the data to be non altered, so that comparisons can be made later on.

See also the following attached sourceFile and workspace;

 

To me it reminds me of the following item I addressed earlier on;

https://knowledge.safe.com/questions/90726/extracting-nested-object-with-jsonextractor-issue.html

in which a JSON Extractor used to convert JSON boolean values (i.e. true/false) to 1/0 boolean values, where I'm glad to see that that got fixed.

To me it only raises some concerns that the handling of these values doesn't seem to occur in a very consistent manner; whereas a JSON fragmenter does seem to keep JSON boolean values intact, initially a JSON Extractor converted these values to 1/0, and now I find that a JSON reader converts these values to Yes/No. :(

Not only JSON, some format readers use Yes/No as representations of boolean values. I don't know why Safe's developers designed like that, but FME considers all of yes/no, y/n, true/false, t/f and 1/0 (case insensitive) as boolean values, so you can convert the representation with a math expression like this.

@CurrentAttribute() ? true : false

0684Q00000ArKMpQAN.png

 


Not only JSON, some format readers use Yes/No as representations of boolean values. I don't know why Safe's developers designed like that, but FME considers all of yes/no, y/n, true/false, t/f and 1/0 (case insensitive) as boolean values, so you can convert the representation with a math expression like this.

@CurrentAttribute() ? true : false

0684Q00000ArKMpQAN.png

 

This is a great tip. Thanks @takashi - your FME Knowledge knows no bounds


Not only JSON, some format readers use Yes/No as representations of boolean values. I don't know why Safe's developers designed like that, but FME considers all of yes/no, y/n, true/false, t/f and 1/0 (case insensitive) as boolean values, so you can convert the representation with a math expression like this.

@CurrentAttribute() ? true : false

0684Q00000ArKMpQAN.png

 

Hi @takashi. Thanks for the response. Currently I (ab)used two NullAttributeMapper transformers to achieve the same result (one for No --> false and one for Yes --> true), but good to see that there is also an alternative. 

Can you maybe explain how I should interpret the expression '@CurrentAttribute() ? true : false' you suggested. To me it seems like it might relate to the idea to allow the 'AttributeValueMapper to work on more than 1 column', as suggested by @1spatialdave; especially seen the background topic he posted with it. 

I get the '@CurrentAttribute()', but the combination with '? true : false' is new to me, and I can't find it in e.g. the documentation page of the ExpressionEvaluator.


Not only JSON, some format readers use Yes/No as representations of boolean values. I don't know why Safe's developers designed like that, but FME considers all of yes/no, y/n, true/false, t/f and 1/0 (case insensitive) as boolean values, so you can convert the representation with a math expression like this.

@CurrentAttribute() ? true : false

0684Q00000ArKMpQAN.png

 

? : is a math operator. x ? y : z returns y if x is true (non- zero), z otherwise. See also here: Math Operators


? : is a math operator. x ? y : z returns y if x is true (non- zero), z otherwise. See also here: Math Operators

@takashi; tnx for the clarification. I think I get it, although the 'non-zero' addition still confuses me a bit (particulary when @CurrentAttribute() = 'No'; one might wonder (i.e. I did) whether 'No' is considered to be true (as textually it is 'non-zero'), but I guess if the associated data type is boolean, 'No' does indeed evaluate to zero (i.e. false)).


Reply