Skip to content
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

Closed
RocketD0g opened this issue Nov 7, 2015 · 8 comments
Closed

South Africa Data - Sources #9

RocketD0g opened this issue Nov 7, 2015 · 8 comments

Comments

@RocketD0g
Copy link

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

@olafveerman
Copy link
Contributor

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

@RocketD0g
Copy link
Author

Another source recently mentioned to us: http://www.saaqis.org.za/RequestData.aspx

@sourabhtk37
Copy link
Contributor

http://live.rbcaa.org.za/Default.htm
You can find the data here.

@dolugen
Copy link
Contributor

dolugen commented Jun 12, 2017

Another source recently mentioned to us: http://www.saaqis.org.za/RequestData.aspx

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 aqicn doesn't have much coverage of the country, let alone the continent.

http://live.rbcaa.org.za/Default.htm

This one only covers the Richards Bay town.

@RocketD0g
Copy link
Author

RocketD0g commented Jun 26, 2017

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.

  1. These data are shared in a very similar way to the Israeli data, shared in this comment: Data from Israel #146 (comment)

  2. Go to http://live.rbcaa.org.za/Default.htm

  3. Click: Dynamic Table->Richard's Bay

  4. Follow similar procedures as Number 5 in Data from Israel #146 (comment)

  • Suggest 15 minute or higher averaged data from stations
  1. Station name and coordinates are accessible by clicking on station name.

@dolugen
Copy link
Contributor

dolugen commented Jul 10, 2017

Data addresses

  • The /MenuSite.aspx file has a variable (search for var o or DynamicTable) that contains data for the Dynamic Table menu items (as well as the Envista system build version).
  • Read the list of station IDs from page /DynamicTable.aspx?G_ID=X
  • Read station coordinates from /StationDetails.aspx?ST_ID=X
  • Read the AQ data from /StationReportFast.aspx?ST_ID=X

Underlying system

Looked 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:

Country Build number in MenuSite.aspx Version number in About.aspx
IL 2.0.20091.207 6.4.14
ZA 2.0.20063.108 4.0.8.9

(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.

@dolugen
Copy link
Contributor

dolugen commented Jul 15, 2017

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.
  */
};

dolugen added a commit that referenced this issue Jul 15, 2017
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
@dolugen
Copy link
Contributor

dolugen commented Jul 16, 2017

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).

jflasher pushed a commit that referenced this issue Aug 11, 2017
* 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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants