Skip to content

Home

Jump to bottom Edit New page
samthetechie edited this page Mar 11, 2012 · 8 revisions

#Who #What ##New development ideas

  • Point-and-click (instead of exit) and terrain-type polygons (instead of zones) based system -- more versatile applications than kettling scenarios.
  • Point-based submission of data can carry descriptive information and/or categories (i.e. police horses, etc).
  • Events as points.
  • Augmented Reality ** http://en.wikipedia.org/wiki/Augmented_reality#Open_source) ** AR Toolkit ** Layar-- proprietary, other possibilities?
  • Minimap instead of compass? a map may permit better decision making in live situations than a compass. summary feed of recent events near me.
  • Push location of oneself and one's trusted friends in a kind of 'radar'?
  • Time and density clustering of points
  • Human moderated or purely automated voting
  • Video feeds from drones.
  • Rich desktop experience for moderators: spatiotemporally perfect data -- live news helicopters, using tivo to pause and record live tv, rotating google earth to match up the picture.
  • International volunteers / in America?
  • The legal jurisdiction of the protest should differ for the people doing the updates to avoid legal pressure.
  • How to combine the distributed, low information/reliability data sources with the few high information/reliability sources?
  • How to avoid counter-intelligence sabotage
  • Allow polyline data that could be used to accurately represent the position of police lines.
  • How do you deal with old data? How do you deal with noise (too many event points on map).
  • If people should be reporting event points as no longer relevant, then a large number of points would make this task cumbersome. Maybe have a way of selecting multiple points and saying they're redundant?
  • Maybe volunteers should be looking at data and angregating/combining points that are duplicates? Work to s simplify the data as it is produced to keep it from getting out of control.
  • Should all user submitted data go through moderation/refinement?
  • Karma system? Should peoples' submitted data be given more weight if they have submitted good data in the past? .. requires submittions to be linked to a user ..

##The Data:

  1. The Zones + Exits (static)

How are Zones + Exit status data linked? Facts:

  • They are in the same data folder
  • They are files like .zone
  • They are files like .exit
  • We used to have <sha2 of protester (email + sallt)>.protester

What ID is used to identify them?

  • The ID was actually the name of the zone or street, there was no 'unique id' or 'key id' as such.

Does ID need to survive across updates?

  • Yes if we dont want to map the id to the current version?
  • The revisioning engine could just be a version number or hash and the list of ID's which correspond to that version (for each given zone and exit)
    • Version 1: id/hash 1,2,3,4,5,6,7,8,9
    • Version 2: id/hash 1,10,3,4,5,6,11,8,9 where record ID's 2 and 7 have been updated and replaced by 10 and 11.
  1. Exit statuses (dynamic)
  • How much data needs to be sent with each update? { exit: 10, status: 2 }
    • Can we State Code these updates? Can we also use entroy to minimise the message length to ensure that the most likely and most frequenyly seen / transmitted events are encoded with the least bits and the more rare events are coded with more bits?
    • Simple coding system: e10,s2 ^^^ The push based services all use json
    • Key Value pairs
      • {key=e, value=10}
      • {key=s, value=2}
  • Push updates to clients.
  • PubNub?
  • Beaconpush?
    • Cheap and pay as you go rather than high monthly fee
    • javascript only message consumption
  1. Database
  • MongoDB has only basic GIS support.
  • postgresql + postgis can do anything, but is much less friendly.

What UID system should be used for Zones/Exits +See line: 16 +Just use MongoDB IDs? +Are they too long? Numerical IDs?

http://shiflett.org/blog/2010/jul/auto-increment-with-mongodb

##The Interfaces:

  1. Mapping (editing of data)
  • Editing Zones/Exits.
  • Modifying Exit statuses.
  • Versioned editing with history.
    • rollback
    • Simple summary of actions eg. "User x deleted zone y"
    • View modification on map?
  1. Clients (Compass + Map)
  • Webapp
  • Android
  • IOS

Download all Zone+Exit data, but use lazy viewport based drawing of data.

Store the KML in Local Storage: http://caniuse.com/#search=local

Only download once. (cache in both webapp and native mobile apps)

Move away from Google Maps?:

  • Leaflet? "A Modern, Lightweight Open-Source JavaScript Library for Interactive Maps"
  • MapQuest tiles?

##Crowd Sourcing:

  1. Exit statuses
  • Trust.
  • Combining public sources with trusted sources.
  1. Zone and Exit data

##APIs

###Client:

  • Zone+Exit data KML static file.
  • Current status of all exits.
  • Pushed Exit status updates.

###Editing:

#Marker clustering: http://www.svennerberg.com/2009/01/handling-large-amounts-of-markers-in-google-maps/ <<<<<<< This is really useful. Comparison of different marker clustering solutions. http://www.appelsiini.net/2008/11/introduction-to-marker-clustering-with-google-maps

Alternative maps:

Storing version history of data. What would it be needed for?

  • Rolling back changes to a previous point in time.
  • Historical record for visualisations after the event.
  • Legal investigations?
  • Creating perspectives through the data to be able to play back an event.

Solutions:

  • Use mongo export and store the result in Git .. are the results of mongoexport consistent enough to make clean revisions / avoid noise?
  • Store a separate history collection which has simple version metadata, and keeps all versions of data, and preserves deleted data.

Polymaps uses SVG which Android browser doesn't support, so Leaflet seems the way to go.

#Where

#When

#Why

#How

#Future

Add a custom footer
Add a custom sidebar
Clone this wiki locally