Trouble writing bracketed string list from a .geojson file input to a string field in Hosted Feature Layer

[AbigailStephens]

We are currently using GeoEvent to regularly pull in a .geojson file from an external source. In this GeoJSON, there is a field that contains several strings, contained in brackets, it looks like this:

"lbl_list": [
    "label 1","label 2"
],

Previously, the contents of the square brackets was written to a string field in the output feature layer, but since we finalized our processing workflow and published a new feature layer from GeoEvent server (using the dialog box in the Output Connector), that field is remaining empty.

I have double checked the field length, and as most features don't contain more than one or two labels, the length of 1024 seems more than adequate to contain all characters. I also checked all our Field Mapper processors to make sure that the field is mapped as expected, and I confirmed that it is.

Has anyone run into a similar problem and found a work-around? Or know what might be wrong in our workflow?

We are currently running GeoEvent Server 10.7.1 on Linux.

[DanWade]

The "brackets" you speak of are what is called an array. It sounds like the data has been modified from what it was at the start of your project.

I might suggest allowing GeoEvent to create a new definition automatically. This should then show this object with an infinity icon instead of the number one.

It is possible your existing output layer will require modification as well. You might then experiment with using this handy processor to break the array: Field Splitter Processors for GeoEvent Server

[AbigailStephens]

Hi @DanWade - thanks for your response! What you mention about that field being an array makes a lot of sense.

So using the logic that this field is an array, I allowed GeoEvent to re-create the definition, but it continued to read that field as a string. I then tried a couple things to try and get the array to read in as such:

1. I reordered the features in the geojson to put one with multiple items in the lbl_list array first, so it looks more like

"lbl_list": [ "label 1","label 2" ],

and not

"lbl_list": [ null ],

However, it still seems to interpret this as a string.

2. My next test was to change the field in the definition manually to a group attribute and add five string "values" fields beneath that (a quick scan of the geojson in question showed this to be the longest label list I could find).

After doing this, I adjusted the GeoEvent Service to map all those values out as "lbl_lilst.value1" (or similar). I then tried two things here, having those values write directly out into separate fields, and adding a field calculator that should aggregate those fields into one string field. Neither seems to have worked.

I opened an Esri Support Case in case this is unexpected behavior, but I am happy to consider any other insights you might have to help with troubleshooting.

[DanWade]

This array behavior for the inbound GeoJSON adapter has been submitted as the following bug:

[BUG-000142930: Inbound GeoJSON adapter is not handling arrays of strings as multicardinal attribute values.]