Crisis Mapping: RDTN.org - Revision history

Wiki-Leo: Reverted edits by AndreaHopper (talk) to last revision by Brian Wilson

2012-10-18T08:26:03Z

Reverted edits by AndreaHopper (talk) to last revision by Brian Wilson

Wiki-AndreaHopper: /* Coping with data sources */

2012-04-12T14:51:54Z

Coping with data sources

Wiki-Brian Wilson: /* Coping with data sources */

2011-04-02T19:42:53Z

Coping with data sources

Wiki-Brian Wilson: /* The assumptions */

2011-04-02T19:39:54Z

The assumptions

Wiki-Brian Wilson at 19:27, 2 April 2011

2011-04-02T19:27:41Z

Wiki-Tchaddad: Created page with 'http://RDTN.org - ''a collective voice helping others stay informed'' Radiation info from Japan and beyond aggregated from a number of sources, displayed via map, soon to be K…'

2011-04-02T06:28:31Z

Created page with 'http://RDTN.org - ''a collective voice helping others stay informed'' Radiation info from Japan and beyond aggregated from a number of sources, displayed via map, soon to be K…'

New page

http://RDTN.org - ''a collective voice helping others stay informed''

Radiation info from Japan and beyond aggregated from a number of sources, displayed via map, soon to be KML feed.

48 hours after design, 72 hours from original sketch

1) made assumptions

2) built a trust network

3) launched early, iterated often

'''Assumptions'''

1) people will buy geiger counters

2) people will trust us

3) radiation units are simple

4) people will understand info on site

5) no one else to solve same problem

6) they are qualified to do this

http://pachube.com (one source for data) - api to query data

Much of the data is scraped from govt or other sources that make it available in difficult to use formats (e.g. daily PDF outputs, or screen dumps). EPA is guilty of having an interface for accessing the data that is relatively useless for App developers. Data.gov doesn't help - almost makes the situation worse by raising expectations (showcases the data on the front page, promises downloadable data, and feeds, but really all the links lead back to the same frustrating EPA interface).

At least one interesting example (from Germany) of a contributing source using crowd-sourcing not to contribute original data, but to transform (scrape) it out of PDFs into usable form...

Return to [ http://wiki.osgeo.org/wiki/PDX-OSGEO#Unconference_Sessions 2011 Unconference Sessions].

← Older revision		Revision as of 08:26, 18 October 2012
Line 52:		Line 52:

	At least one interesting example (from Germany) of a contributing source using crowd-sourcing not to contribute original data, but to transform (scrape) it out of PDFs into usable form. Volunteers read the PDF reports and re-enter data in a machine-readable format.		At least one interesting example (from Germany) of a contributing source using crowd-sourcing not to contribute original data, but to transform (scrape) it out of PDFs into usable form. Volunteers read the PDF reports and re-enter data in a machine-readable format.
−
−	~~[http://www.resumesplanet.com/resume_writing.php writing resume]~~


	Return to [[PDX-OSGEO#Unconference_Sessions\|2011 Unconference Sessions]].		Return to [[PDX-OSGEO#Unconference_Sessions\|2011 Unconference Sessions]].

← Older revision		Revision as of 14:51, 12 April 2012
Line 52:		Line 52:

	At least one interesting example (from Germany) of a contributing source using crowd-sourcing not to contribute original data, but to transform (scrape) it out of PDFs into usable form. Volunteers read the PDF reports and re-enter data in a machine-readable format.		At least one interesting example (from Germany) of a contributing source using crowd-sourcing not to contribute original data, but to transform (scrape) it out of PDFs into usable form. Volunteers read the PDF reports and re-enter data in a machine-readable format.
		+
		+	[http://www.resumesplanet.com/resume_writing.php writing resume]


	Return to [[PDX-OSGEO#Unconference_Sessions\|2011 Unconference Sessions]].		Return to [[PDX-OSGEO#Unconference_Sessions\|2011 Unconference Sessions]].

← Older revision		Revision as of 19:42, 2 April 2011
Line 54:		Line 54:


−	Return to [[Unconference_Sessions\|2011 Unconference Sessions]].	+	Return to [[PDX-OSGEO#Unconference_Sessions\|2011 Unconference Sessions]].

@@ Line 13: / Line 13: @@
 ) launched early, iterated often
-=== The assumptions ===
+== The assumptions ==
 ) people will buy geiger counters
@@ Line 26: / Line 26: @@
 ) they are qualified to do this
 The presentation stressed that many of these assumptions are, in fact, wrong.
 But the sense of urgency created momentum that allowed the developers to overcome the faulty initial assumptions and to push on to create something of value.
-Operating in crisis mode allows more quickly building a network of contacts. One of the connections led to http://pachube.com/ (pronounced "patch-bay") Pachube has a network of sensors so they became a source for data with an api allowing direct queries).
+Operating in crisis mode allows more quickly building a network of contacts. One of the connections led to [http://pachube.com/ Pachube] (pronounced "patch-bay"). Pachube has a network of sensors in place around the world, so they became a source of data.
 In ordinary circumstances, Pachube would have been seen as a competitor that might have derailed the whole project. ("It's been done already, let's just skip it!") In crisis mode, Pachube became a valued collaborator.
-Much of the data in RDTN.org is scraped from government or commercial sources. Scraping is necessary because these agencies make data available in polished reports (eg daily PDFs or screenshots) that are easy to view but difficult to harvest as data sources.
+== Coping with data sources ==
-US EPA for example, has an interface for accessing the data that is relatively useless for app developers. Data.gov doesn't help either - almost makes the situation worse by raising expectations. Data.gov showcases the data on the front page, promises downloadable data, and feeds, but really all the links lead back to the same frustrating EPA interface. To be fair, the sharing of data via feeds is still in its infancy, and as one attendee commented, GIS data was in the same situation only a few years ago.
+To be fair, the sharing of data via feeds is still in its infancy, and as one attendee commented, GIS data was in the same situation only a few years ago.
 At least one interesting example (from Germany) of a contributing source using crowd-sourcing not to contribute original data, but to transform (scrape) it out of PDFs into usable form. Volunteers read the PDF reports and re-enter data in a machine-readable format.

@@ Line 1: / Line 1: @@
-http://RDTN.org - ''a collective voice helping others stay informed''
+Presentation by Uncorked Studios on their project [http://RDTN.org/ RDTN.org] - ''a collective voice helping others stay informed''
-Radiation info  from Japan and beyond aggregated from a number of sources, displayed via map, soon to be KML feed.
+RDTN.org maps radiation info from Japan and beyond, aggregating data from a number of sources. Soon to be a KML feed.
-hours after design, 72 hours from original sketch
+The site rolled out just 72 hours after the original "back of envelope" sketch.
-) made assumptions
+== How it happened ==
 ) built a trust network
@@ Line 11: / Line 13: @@
 ) launched early, iterated often
-'''Assumptions'''
+=== The assumptions ===
 ) people will buy geiger counters
@@ Line 25: / Line 27: @@
 ) they are qualified to do this
-http://pachube.com (one source for data) - api to query data
+Much of the data in RDTN.org is scraped from government or commercial sources. Scraping is necessary because these agencies make data available in polished reports (eg daily PDFs or screenshots) that are easy to view but difficult to harvest as data sources.
-Much of the data is scraped from govt or other sources that make it available in difficult to use formats (e.g. daily PDF outputs, or screen dumps). EPA is guilty of having an interface for accessing the data that is relatively useless for App developers. Data.gov doesn't help - almost makes the situation worse by raising expectations (showcases the data on the front page, promises downloadable data, and feeds, but really all the links lead back to the same frustrating EPA interface).
+US EPA for example, has an interface for accessing the data that is relatively useless for app developers. Data.gov doesn't help either - almost makes the situation worse by raising expectations. Data.gov showcases the data on the front page, promises downloadable data, and feeds, but really all the links lead back to the same frustrating EPA interface. To be fair, the sharing of data via feeds is still in its infancy, and as one attendee commented, GIS data was in the same situation only a few years ago.
-At least one interesting example (from Germany) of a contributing source using crowd-sourcing not to contribute original data, but to transform (scrape) it out of PDFs into usable form...
+At least one interesting example (from Germany) of a contributing source using crowd-sourcing not to contribute original data, but to transform (scrape) it out of PDFs into usable form. Volunteers read the PDF reports and re-enter data in a machine-readable format.
-Return to [ http://wiki.osgeo.org/wiki/PDX-OSGEO#Unconference_Sessions 2011 Unconference Sessions].
+Return to [[Unconference_Sessions|2011 Unconference Sessions]].