Simon -Polling the feed you indicated: [url=http://pipes.yahoo.com/pipes/pipe.run?_id=7892c39c1778e81c27aeb4a0ba265623&_render=json]http://pipes...] it appears to me that all of the items event fields are being expressed as JSON strings, with the first item in the list advertising the expected field names.
:
:
items: [
{
Site: "Site",
LastSampleTime: "Last Sample Time",
RiverLevel: "River Level",
FlowRate: "Flow Rate",
RainfallIntensity: "Rainfall Intensity",
WaterTemp: "Water Temperature",
Conductivity: "Conductivity",
description: null,
title: null
},
{
Site: "210001-Singleton",
LastSampleTime: "30/04/2014 05:57:56",
RiverLevel: "0.652",
FlowRate: "400.2",
RainfallIntensity: " ",
WaterTemp: " ",
Conductivity: " ",
description: null,
title: null
}, ...
The GeoEvent Definition generated for me by the GeoEvent Processor input specifies that all fields are expected as String:[ATTACH=CONFIG]33454[/ATTACH]When I send the poll'd JSON to a GeoEvent Cache, I can review the event data as either Text or JSON by visiting the appropriate REST endpoint for the cache:- localhost:6180/geoevent/rest/cache/cache-out?f=text
- localhost:6180/geoevent/rest/cache/cache-out?f=generic-json
The GeoEventCache adapter used by the Publish GeoEvents on a REST endpoint appears to be handling the unicode string/character \u00a0 being reported when values are missing/unreported as part of the unicode extended character set.[ATTACH=CONFIG]33455[/ATTACH]The Text adapter used by the Publish text to a TCP Socket, on the other hand, appears to be converting the "non breaking space" character ... which in HTML is &# 160; ... to an ASCII extended character equivalent: á.What you could do, to avoid having this unicode character being interpreted by different adapters, is edit the generated GeoEvent Definition to specify that the metric values are expected as type Double. The input will then attempt to cast the JSON string values it receives to Double, and set the field's value to null if the type cast fails. Might as well include the description and title event fields from the provided JSON, currently being reported as null strings, while you're at it:[ATTACH=CONFIG]33457[/ATTACH]Notice in the following illustration that in a "text" adaption of the event data, the null fields appear "empty", while in a JSON adaption of the event data the null fields are not reported.[ATTACH=CONFIG]33459[/ATTACH]I think this will better allow you to apply filter criteria, process events, and eventually send event data to a feature service. Better, in my opinion, to send "null" data as null than as a "non-breaking space" unicode character.- RJ