HTTP Interface

GET Requests

Heat map overlays

These requests allow you to access the map overlays, which are PNG images. Below are the URLs for the current overlays, which update as new reports arrive during the simulation:

http://localhost:8000/web/mapdata/map_test1.png: the HeatMapBCC predictions.
http://localhost:8000/web/mapdata/map_test_sd_1.png: the HeatMapBCC uncertainty.
http://localhost:8000/web/mapdata/map_test_rep_intensity_1.png: the report intensity, i.e. predictions based on reports only, with no interpolation.
http://localhost:8000/web/mapdata/map_test_rep_intensity__sd_1.png: the uncertainty if you use reports only, with no model to interpolate between them.

Below are the URLs for the final heatmap overlays for the complete heatmaps once all the reports have arrived and the simulation is complete.

Lists of Predcted Targets

http://localhost:8000/web/targets.json: a list of predicted targets, e.g. emergencies. These will be points of high probability of a target. The expected value of sending a responder to these locations is high.
http://localhost:8000/web/final/targets.json: the final list of predicted targets after all reports have been received and a "complete" heatmap has been constructed.
Not yet implemented: http://localhost:8000/web/recon.json: a list of possible targets, e.g. emergencies, with low certainty. These are points where we need more information before sending in rescuers, for example. Points with highest value of expected entropy reduction * pr(target). This is lower priority for implementation for the demo.

Both of these URLs will return json objects containing a list of objects. Each object in the list represents a target using a list with the following entries:

[0]: ID of target
[3]: the ID of the type of target. These may be assigned at random in the simulation.
[4]: version number
[5]: list of associated reports
[6]: confusion matrices of reporters/information sources
[7]: IDs of information sources

PUT Request

This allows you to add new reports by submitting HTTP form data with the following fields:

c_val: 0 or 1. Whether the report is positive or negative, i.e. confirming events/targets/damage in an area (1) or reporting no events/targets/damage (0).
type: 1. This is the event type. At the moment the Ushahidi map displays only one type of target, "emergencies". This will in future be able to produce different overlays.
lat: real value latitude of report.
lon: real value longitude of report.
rep_id: -1 or 0. If you enter "-1", a new ID number will be created for a new reporter. If you enter "0" you must also set the field "reporter" as an existing ID will be used.
reporter: any integer specifying the reporter ID to be associated with this new report. If you want to set the reporter ID using this field, you should also set the field rep_id=0.
trust_acc: real value between 0 and 1. This field is used when a new reporter is added and sets their prior trust. A trusted source should have a high value here.
trust_var: real value > 0. This is actually the precision, i.e. the certainty about how accurate the reporter is. If the reporter is well-known a priori, this value should be high, e.g. 200. If we don't really know how reliable they are, set it to 12 and the machine learning code will figure out the reliability of this reporter from the data. Any value less than 12 might cause wierd things to happen!

Some of these fields ought to be renamed, sorry!

Example

An example of how to do this can be seen by looking at the web interface in web/crowdReporter3.html, line 48. This code defines a javascript function that will be called when the submit button is clicked. This function reads the input fields from the HTML form and constructs a data dictionary. The data dictionary is POSTed to the web server in line 70 using the jquery function $.post().

Provide feedback

Saved searches