You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Because of the way that we are linking locations (nodes) to providers and then using that information in the data export paths we are seeing situations where a location is flipping back and forth between different 'folders' in our export file structure.
A good example of this can be seen in location 8047. This location is part of the AirNow/StateAir networks and is ingested (historically) under both. Because of the way that data is updated for realtime ingestion we are seeing the provider move back and forth between AirNow and StateAir, so, for a given month, this is what the exports look like
We can see this in the sensor_nodes_history table. Here is a summary of the last 30 days which shows how many times the node was updated and which source_name it was updated to. A day with two sources is a day that it switched at least once
This summary is from production but staging is similar
The solution to part of this is going to be the source/providers updates we have been talking about. The other issue, for example the node being updated every time we are ingesting will require some reworking of how we are comparing nodes on ingest.
The text was updated successfully, but these errors were encountered:
Because of the way that we are linking locations (nodes) to providers and then using that information in the data export paths we are seeing situations where a location is flipping back and forth between different 'folders' in our export file structure.
A good example of this can be seen in location 8047. This location is part of the AirNow/StateAir networks and is ingested (historically) under both. Because of the way that data is updated for realtime ingestion we are seeing the provider move back and forth between AirNow and StateAir, so, for a given month, this is what the exports look like
We can see this in the
sensor_nodes_history
table. Here is a summary of the last 30 days which shows how many times the node was updated and which source_name it was updated to. A day with two sources is a day that it switched at least onceThis summary is from production but staging is similar
The solution to part of this is going to be the source/providers updates we have been talking about. The other issue, for example the node being updated every time we are ingesting will require some reworking of how we are comparing nodes on ingest.
The text was updated successfully, but these errors were encountered: