High radiation values disappearing from kml file

[Anagha Uppal]

log files generated from our geiger counters, when uploaded to the Safecast website and visualized display a few high radiation values. When we download the same files as kml files, however, in order to explore them in depth using GIS software, we notice that although the number of readings (rows) remains the same, many high values are dropped from the files (they are getting changed or something). Has anyone else faced something like this?

[Mat Schaffer]

I haven’t heard of that yet. Can you send a link as an example?

The kml conversion is programmatic so could be we have a bug. 

On Mon, Mar 30, 2020 at 6:16 Anagha Uppal <ana...@gmail.com> wrote:

log files generated from our geiger counters, when uploaded to the Safecast website and visualized display a few high radiation values. When we download the same files as kml files, however, in order to explore them in depth using GIS software, we notice that although the number of readings (rows) remains the same, many high values are dropped from the files (they are getting changed or something). Has anyone else faced something like this?

--
You received this message because you are subscribed to the Google Groups "Safecast Device Discussions and Support" group.
To unsubscribe from this group and stop receiving emails from it, send an email to safecast-devic...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/safecast-devices/35e7a059-43a6-4029-9521-3b90483033fb%40googlegroups.com.

--

-Mat

matschaffer.com

[Mat Schaffer]

No problem Anagha. Hope you don't mind me bringing this back to the mailing list.

Pretty sure what's happening here is that the viewer has special code that will swap in the cpm5s at cpm values over 100: https://github.com/Safecast/Tilemap/blob/master/bgeigie_viewer_worker.js#L338-L343

But the kml export doesn't have any special handling https://github.com/Safecast/safecastapi/blob/master/app/views/bgeigie_imports/bgeigie_logs.kml.erb#L166-L167

We could potentially have the `usv` function implement similar logic https://github.com/Safecast/safecastapi/blob/master/app/models/bgeigie_log.rb#L22, maybe +Nick Dolezal would be good to comment on if that's a good idea or not since he implemented the viewer logic.

Looks like it might be tricky to implement w/o some handling of the points prior to the swap (just from reading the high_n part of the viewer implementation)

On Mon, Mar 30, 2020 at 9:10 AM Anagha Uppal <ana...@gmail.com> wrote:

Dear Mat, 

THANK YOU so much for your time and your response! I'm attaching one such log file, the resulting KML file and the Safecast Google map (the map shows the one bright pink value as having a 0.79 uSv reading that is missing from kml) that had this issue and we are hoping dearly you have some ideas for us!! 

You can grab the file: curl https://api.safecast.org/en-US/bgeigie_imports/46616?format=json&id=46616