New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
South Africa Data - Sources #9
Comments
Quick note, the above site makes heavy use of iframes. The table with the data can be found on this url: http://live.rbcaa.org.za/DynamicTable.aspx?G_ID=1 |
Another source recently mentioned to us: http://www.saaqis.org.za/RequestData.aspx |
http://live.rbcaa.org.za/Default.htm |
This is a slow one. You submit your request and have to wait. Not a good channel for OpenAQ. It aggregates data from all other South African data providers. It would be nice if we had a direct access to it. Even This one only covers the Richards Bay town. |
Given @dolugen's comment, above, this one just focuses on the Richard's Bay data source (http://live.rbcaa.org.za/Default.htm) and organizes the data source for dev review.
|
Data addresses
Underlying systemLooked around a bit, and found that the Israeli and South African sources both use the Envista Web system. Maybe they could share a single adapter that handles Envista sources. Although they share similar "build numbers", their advertised version number differs:
(Turkey's system has the same build number as Israel's) I think @maxgrossman (he just started working on the Israeli adapter) and I should attempt to make a unified Envista adapter. We'll see. Edit: The build numbers are from a web component that's used in the system. |
I spent some excess amount of time debugging an export issue in the adapter, which at the end was an issue with the export page. In short: the export functionality was throwing the same files for different station exports. This is worked around by giving each station requests their own cookie jar. There are a few things that should be improved, but overall, the adapter is in working order. Currently, a URLencoded XML is hardcoded in the adapter. The following is a note for dealing with that (moved it out of adapter to keep it cleaner): const getLstMonitors = function () {
/*
TODO
An XML tree that describes the checkedness of
the monitors is URLencoded and passed as a string parameter
in the form.
It looks like below when decoded, going up to 20 something monitors:
<WebTree><Nodes><lstMonitors_1 Checked="true"></lstMonitors_1><lstMonitors_2 Checked="true"></lstMonitors_2><lstMonitors_3 Checked="false"></lstMonitors_3></Nodes></WebTree>
It cannot be queried with cheerio, as it's generated
on the client. But as structure of the tree is known,
it can be generated using the list of monitors and their tag ID.
*/
}; |
Each station has their own cookie jar to avoid server export issue (see #9) TODO * Customize lstMonitors to reduce response size * Try to cut out unuseful stations early
With the report form properly customized, the adapter is dealing with smaller export file, and some useless stations are skipped early. This takes the adapter's running time from 4min down to about 1min. I'm done with this source, but I'll be looking at adapting the adapter for other countries (e.g. Israel). |
* WIP Richards Bay adapter Done: - Get cities list - Get stations list - Query station - Get CSV Todo: - Parse CSV - Format data * Script to get Richards Bay station coordinates * Fix country field in source file * Working adapter Each station has their own cookie jar to avoid server export issue (see #9) TODO * Customize lstMonitors to reduce response size * Try to cut out unuseful stations early * Lint fix * It wasn't timing out after all * Keep the todo on the issue * Customize lstMonitors, only get what you need * Lint... * Skip boring stations * Attemp to customize envista adapter for Israel * Works perfect 90% of the time * Use retry and parallelLimit * Support both IL, ZA in Envista adapter * Use different request objects for each source * Custom form handling for each source * Use region name as city * Skip non number measurement values * Get attribution name from source * Other conditionals based on source country * Change adapter name * Gotta keep Travis happy, lint * Add Israel station coordinates Max wrote the helper script in adapters/israel branch, I made a few modifications: * The returned locations are now a single hashmap, instead of a list of objects * Use stationID to map coordinates, to avoid the unicode key problem. I used the same stationID trick from the Moscow adapter. See the following comment about the problem: #301 (comment) * Lint with updated eslint (Mine was older than what was on Travis) * Skip 0,0 coordinates * Remove outdated envista_za.js adapter
Listed as a priority because we currently do not have any data from the entire continent of Africa.
Data: http://live.rbcaa.org.za/Default.htm
Coordinates: Click on station/station information for coordinates
('trs' in pollutant table is 'total reduced sulfur' - we won't want it
The text was updated successfully, but these errors were encountered: