Does anyone know if there is case info / location info for Europe?

http://nbviewer.ipython.org/gist/arsenovic/d44166390b50f9f15df3

https://gist.github.com/d44166390b50f9f15df3

I was wondering if we could also record in this repo main local (at the contry scale) or global (i.e. wordwide) responses to fight the virus. E.g.:

date: 2014-08-08
actor: WHO
action: "Outbreak is an international public health emergency"
source: "http://en.wikipedia.org/wiki/Ebola_virus_epidemic_in_West_Africa"

date: 2014-08-24
actor: WHO
action: "Ebola Respons Roadmap"
source: "http://apps.who.int/iris/bitstream/10665/134771/1/roadmapsitrep_24Sept2014_eng.pdf"

date: 2014-09-18
actor: UN
action: "Threat to international peace and security"
source: "http://www.bbc.com/news/world-africa-29262968"

date: 2014-09-19
actor: "Sierra Leone"
action: "Three-day lockdown"
source: "http://www.nytimes.com/2014/09/20/world/africa/ebola-outbreak.html"

Add the report date as a column in all digitized sitreps from Guinea. cc @pallih

Someone in irc ##ebola asked about the licence used for the data in this repo. Its not something I've thought about but its probably a good idea to define one. There are a number of applicable licenses. My inclination would be to use the most open one possible - cczero - which is essentially the public domain.

http://creativecommons.org/publicdomain/zero/1.0/

putting a text file of LICENSE in the top-level directory is the normal way to signify the license in use.

Other options are the Gnu free documentation license, the MIT license, etc.

This has to exist right?

Figure out a way to make clear which Guinea situation reports have already been converted to PDF, and which still need to be done. I want to keep the PDFs in the repo even after they are digitized, since they are not available easily available online like the SL and Liberia sitreps.

this is so github will render the markdown file for people who are just browsing the repo

I noticed in the locations.geojson file that some of the coordinates are off -- 3 locations in Guinea are getting converted to [-104.798844, 39.87166390000001], which is in Denver, Colorado. Not sure how this is happening but will try to track it down as time permits.

    {
      "type": "Feature",
      "properties": {
        "address": "Gueckedou",
        "country": "Guinea"
      },
      "geometry": {
        "type": "Point",
        "coordinates": [
          -104.798844,
          39.87166390000001
        ]
      }
    },
   {
      "type": "Feature",
      "properties": {
        "address": "Dinguiraye",
        "country": "Guinea"
      },
      "geometry": {
        "type": "Point",
        "coordinates": [
          -104.798844,
          39.87166390000001
        ]
      }
    },
    {
      "type": "Feature",
      "properties": {
        "address": "Nzerekore",
        "country": "Guinea"
      },
      "geometry": {
        "type": "Point",
        "coordinates": [
          -104.798844,
          39.87166390000001
        ]
      }
    },

Most likely caused after folder refactoring.

the casetree.png just needs a new reference link, but the other images seem to be deleted?

@cmrivers
Could you join our team to do ebov epidemic analysis?

http://www.who.int/csr/disease/ebola/2014-0728-donor-update-ebola-final.pdf?ua=1
http://apps.who.int/iris/bitstream/10665/132834/1/roadmapupdate8sept14_eng.pdf?ua=1

Would be nice to add these in.

Hello,

After my last merge from upstream/master this file is showing up as untracked

"drcongo_data/originals/OMS_Rapport de Situation 01_Cas de gastro-ent\303\251rite h\303\251morragique et f\303\251brile.pdf"

After removing it locally, git thinks it needs to be git removed, which is weird. git ls-files shows it has been removed.

Per @donpdonp:

The dates are all ahead by one day.
The file "2014-08-13-v77.csv" contains CSV data that says 8/13/2014 from report 77.

The problem is the data is from report 77 but report 77 contains data from 2014-8-12 (it was reported on 2014-8-13).

the date field for Sep 25,26,27,30 use a 2 digit year, it should be 4.

It could be helpful to run with a consistent naming convention like country-datasource-YYYY-MM-DD.csv, e.g. liberia-case_reports-2014-09-29.csv - I think it might make sorting and browsing a little easier.

It might also help with #37 so that guinea-report-2014-09-29.pdf could sit next to guinea-report-2014-09-29.csv and you'd have a better idea what still needs to be digitized.

How do you feel about changing the variable names to be consistent across countries? Right now it is a mix of the variables as described in the sitreps (which include whitespace and punctuation), and more machine-friendly shortened variable names. The change would cover both old and new files. cc @pallih

https://blog.scraperwiki.com/2013/07/pdftables-a-python-library-for-getting-tables-out-of-pdf-files/

Not sure if there's a canonical way to cite a github repo, but it seems like it'll be a good idea for this repository. This is one example I took from here

Rivers C., Ebola, (2014), GitHub repository, https://github.com/cmrivers/ebola/

Just in case my message on SL data file 2014-11-10.csv gets missed, there are inconsistencies with the data "dates" from Oct 31st onward - I am currently going through to put the correct date for which the data are describing, which is typically one day prior to the SitRep publication date. On Nov 12/15th, the file names changed from reflecting the date for the data to describing the date on which the report was published. This is confusing. I propose changes to those file names to match the date for the data they describe. Keeping the SitRep Version # is brilliant though. It's a shame the health ministry does not use a date system to identify each report in the file name!

This has to exist right?