GeoEvent Field Mapper - from flat to multicardinality

SpatialSean

I have a flat dataset that needs to be shifted into multicardinality for the output but am struggling with what syntax needs to be used within the field mapper to go from the 1 to many.

I need to take my fields such as language, event, urgency, and effective and then map them to be included into "info" - It may take multiple sets of field mappings to get it correct.

I've gotten as far as knowing there needs to be a '.' in the field mapper else it fails. For example trying to push the string 'Weather' as a category which is also a many.

 

[ Edited:  RJ Sunderman 5/1/2024 7:11 pm ] What @SpatialSean wants to do is (practically) impossible. A custom processor is the best approach for this. Refer to my comment below.

 

 

 

{
   "identifier": "123456789",
   "status": "Actual",
   "msgType": "Alert",
   "scope": "Public",
   "sent": "2019-05-28T13:49:09+0000",
   "info": [
      {
         "language": "en",
         "event": "Test Basic Custom Feed Event",
         "urgency": "Immediate",
         "severity": "Minor",
         "certainty": "Observed",
         "description": "This is a sample description",
         "headline": "Sample Headline",
         "web": "http://www.everbridge.com/",
         "effective": "2019-05-28T13:49:08+0000",
         "category": [
            "Transportation",
            "Local Disaster"
         ],
         "area": [
            {
               "areaDesc": "25 Corporate Drive Burlington, MA",
               "polygon": [
                  "-71.07593,42.50798 -71.20801,42.59766 -71.30529,42.55079 -71.31828,42.52278 -71.07593,42.50798"
               ]
            }
         ]
      }
   ]
}

  "language": "null",
  "event": "Late March Storm System for Plains and Midwest - Snow 3",
  "urgency": "null",
  "severity": "null",
  "certainty": "null",
  "effective": "Sat Mar 23 07:00:00 EDT 2024",
  "expires": "Wed Mar 27 19:00:00 EDT 2024",

 

 

 

RJSunderman

@SpatialSean -- Apologies for joining this discussion late. I don't think what you want to do can be done out-of-the-box using the available configurable processors. None of the processors support hierarchical output. There was strong bias toward flattening an event record's data structure in order to make adaption easier when using an output such as Add a Feature to add an event record's data as a new feature in a geodatabase.

• We never implemented a workflow which will take a flat data schema and allow you to recombine elements to place them into lists or groups.
  
  
• Practically speaking, given anything other than the simplest of event record data structures, developing your own custom processor is the best approach.
  
  

I mean, you could try to configure a series of out-of-the box Field Calculator processors to take input like:

{
  "key_01": "November",
  "key_02": "Alpha",
  "key_03": 1714613432
}

And serialize it into a JSON string like:

{ "keys":  [{ "key_01": "November" }, { "key_02": "Alpha" }, { "key_03": 1714613432 } ]}

But that's really impractical. The expression needed to do this would look something like:

'{' + ' "keys": ' +
' [{' +
    ' "key_01": ' + '"' + key_01 + '"' + ' }, ' +
    '{' +
    ' "key_02": ' + '"' + key_02 + '"' + ' }, ' +
    '{' +
    ' "key_03": ' + key_03 + ' } ' +
']}'

Using simple string concatenation to construct a raw JSON string with more than just a few attribute values is going to become unmanageable very quickly. Especially when you get to the JSON string representation of a polygon with its embedded brackets, commas, and quoted keys. Even if you condense some of what I have above and combine values I've separated as literal strings into fewer single-quoted literal strings ... I was trying to make the illustration somewhat readable ... an out-of-the-box approach just isn't feasible.

Wanted to comment to confirm limitations --
RJ