Human Map :: The living breathing first hand experience of world events.

The Missing Piece

With very little cooperation from existing infrastructure we stand on the verge of comfortably accessing an "input stream" comprised of each individual's needs wherever disaster occurs. Such a system should cost nothing to the end user because it actually saves significant sums in wasted effort and wrong guesses. Early warning alone could mean regime change, or halting epidemics.

A citizen with featurephone should be able to have a contact within minutes of catastrophic event and a buzz as each new tower comes back online, to capture as many weak signals and potential survivors as possible. The signaling of new towers will reassure each individual that systems are returning. Individuals should be able to initiate a Need whenever it comes up.

Region Level Shortcodes can be negotiated and should be part of any provider's operating agreements, but the intended operation of this system is accomplished through wide broadcasts of short questions and responses. For survival level conversations there is a very brief set of actions required. Sending requests and being updated about the progress of an request seems like the most useful mechanism in low resource situations. This kind of conversation doesn't need to be synchronous or 'live' in the sense of a voice connection, but certainly live enough when the system is providing progress updates steadily.

In time, opening up the ecosystem of devices that can interact with this protocol will more resemble electronic nerves.

The data and all reporting is owned by the sender.Permission to track, edit, delete or escalate at will is owned by the Sender. This is exactly opposite the typical direction of civic information. The feedback mechanisms and display ought to show every communication and reference associated with the published Need, until resolution. The 'Need' is an entity with a location, representing a resource's presence or lack, with a description (text, audio, photo, video).

The cultural connotation of 'Need' that makes most sense and fits the intention can be a variable. The Need has input, feedback, performance metrics and satisfaction data discoverable in the transaction logs. As an entity, it is able to broadcast requests, set virtual 'beacons' to repeat distress signal messages until response. Other actions would be set for when the phone battery dies. Perhaps a very low power drain sequence of bursts. I should know the status of those nearby so that I can offer, or request help. This again though, happens peer to peer rather than from a government or agency looking down. As a Need is echoed by others, it gains in 'reputability' and rises among the 'community view'. The decision of 'where' to send the Need is made by the Sender based upon a dashboard of respondents. Much like an inventory and ordering process. There is a cultural limitation (Some call a colonial attitude) that 'people can't be trusted' but disasters prove otherwise. Individuals in crisis can be presented with a set of tangible options. Also a view of what others naearby are asking for. Joining their 'request' has some advantages in some scenarios.

Why would they participate? Simple efficiency. Knowing a need or cluster of similar Needs is a solution to many logistics headaches that plague aid delivery. A list of predetermined needs and details creates efficiencies all they way up the supply chain. Predictive inputs would work in this case because it is citizens directly expressing their priorities to neighbors and forwarding to governance as needed. Not responding would be immediately known to all of the individuals in the system who are now stakeholders. Crowdmapping data flow is typically from: public to: a select group of public, all hoping that decision makers get to see it. The preferred flow is from citizens to one another and then to regional representation or agency or ngo as needed, to restore normalcy. Letting citizens decide from what's available introduces self-efficacy into traumatic events and improves psychosocial outcomes. "This is how I want to rebuild:" ought to be possible for every disaster survivor to be able to say.

For Municipal development, locals are listened to, but their ability to be at the forefront of decision making has only recently become a foreseeable reality. It remains to be seen to what degree innovation will be adopted, but the honest attempt has only been tried in fits and starts. There is no therapeutic reason to keep control of resources at the NGO or Agency level. Accordingly, if a few agencies display similar items in their warehouses it ought to be up to the Sender to decide which aid, from whom and how the aid is delivered. In this way reviews of past experiences can be collected and aid received from entities who prove themselves worth working with. An ecosystem of sensors and users could arise that thrives on mutual aid. If local resiliency programs prove efficacious then some level of governmental support becomes a very economical investment in efficiency. Letting citizens determine their recovery also allows for creativity that Ministers cannot recreate. Putting the onus then, on agencies to coordinate their own distribution system and governments to streamline the process of delivery because valid quantified data is streaming in from the countryside. Assessment and categorization would have already been accomplished by the Senders and verified by a third party as needed, but the rest is academic. With feedback loops, even austere environments can receive sufficient updates to spot and track theft during transport. Making citizen involved policy decisions reach out to the farthest reaches of humanity. Right now.

So, the system thus far consists of a server-side component and user-screen interface. Each successively complex layer of technology: smartphone, tablets, notebook, desktop etc. would be putting compute resources to rendering larger swaths of 3D and performing file conversion on new datasets as needed. The "views" (facets?) are what is being stored and shared as a collection of URL's to datasources. Back-end connections to local layer storage should be a priority, but layers are so important it seems better to have a separate tool. Layer hosting is not the object of this system. Neither is the point to produce a high volume of different maps, but rather a consistent use of really effective ones with access to thematically similar items. The addition of screen real estate puts more interaction options in front of the user. More resources are required server side for lower technology use, and more workflow process must occur at server level before being converted to featurephone interaction, but this is also the most important level of the system's operation.

To be truly compassionate, the hardware nodes for such a system would need to rely upon safe components, free from conflict or exploitative history. I have been also advocating for a Personality Server for some time. A small device or cloud-mirrored storage and interaction exchange that would be an arbiter of one's personal presence online. Storing the tools and data most relevant to one's life. Operating in Peer to Peer mode for sharing content with one's trusted contacts and RSS for updates to one's various communities and social networking services. I imagined that advertisers and commerce would request information and pay for access directly to the user. When a device was not in actual operation, mining Bitcoin is as viable purpose as any, providing idle time profitability particularly with solar powered installations. A modular design would allow for add-on hardware like GPU banks to speed up the mining process. It also would be useful to act as VPN tunneler to provide anonymity through network packet scattering.

As for the screen experience, the software provides a map with layers. The layers can be manipulated using drag and drop filenames with mathematical operators between them. This would enable complex ideas to be conveyed without looking at stacks of tabular data. The resultant window title becomes the names of the layers themselves and the operator state should be retained in the object header. The collection of imagery URL's, vector files, operators and filters could be called a "Perspective" and could be editable in applications like QGis just by inflating the contained layer files. Operators would be overlooked in the XML and available the next time they were opened in the system. Over time the header information format would be adopted to show comparisons and analytical content in other software packages.