Differences between revisions 1 and 2
Revision 1 as of 2002-06-17 04:21:04
Size: 3757
Editor: user-uini6a1
Comment:
Revision 2 as of 2002-06-17 04:25:48
Size: 4128
Editor: user-uini6a1
Comment:
Deletions are marked like this. Additions are marked like this.
Line 5: Line 5:
Some of these goals are obviously ones for futher down the road, but hopefully thinking about them early one will allow us the better achieve our end goals. For a list of current wishes for the WnDb software please see the WnDbDevel page. Some of these goals are obviously ones for futher down the road, but hopefully thinking about them early on will allow us the better achieve our end goals. For a list of current wishes for the WnDb software please see the WnDbDevel page.  -- AdamShand
Line 13: Line 13:
 * It should monitor nodes for availability and be able to present that information when people are searching for or viewing nodes.  * It should monitor nodes for usage metrics and availability and be able to present that information when people are searching for or viewing nodes.
Line 18: Line 18:
 * It should use a projection (and ideally a data source like MapBlast) which will work world wide.  * It should use a projection (and ideally a data source like MapBlast) which will work world wide.  Ideally it should be able to serve node data with different backends (street data, elevation data, topographical data etc).
Line 20: Line 20:
 * It should be able to draw lines between nodes where connectivity exists and map out the logical network.
 * It sould be able to act as an IP management solution to allow node owners and the SpecialOps team to easily track and manage which nodes are supposed to belong to which networks.
Line 21: Line 23:
 * It should be capable of monitoring the nodes and generating usage statistics from that data.
Line 25: Line 26:









There are lots of ideas how and what our MappingSoftware (currently the WnDb) should do. Here's the beginnings of a list of requirements for a possible rewrite by SethShikora.

The mapping software is the technical heart of the community. It is what shows us what we've accomplished and allows us to set and meet goals. By measuring usage statistics it is also what allows node owners to feel the PrideOfOwnership and understand their contribution to the network. Due to the volunteer nature of a CommunityNetwork it should be as self maintaining as possible and as decentralized as possible.

Some of these goals are obviously ones for futher down the road, but hopefully thinking about them early on will allow us the better achieve our end goals. For a list of current wishes for the WnDb software please see the WnDbDevel page. -- AdamShand

  • It should be simple to install and maintain and have as few external dependancies as possible. This is because other CommunityWireless groups will need to be able to set it up for themselves.

  • It should have a notion of nodes, people and usage metrics.
  • Any data storage schema (SQL?) should be as generic as possible to allow future ideas to be worked with.
  • It should be able to exchange node data with other instances of the MappingSoftware which is run by other groups (GAWD by the ShmooGroup is a possible data exchange format). This means it should segregate information by group and have notions of authority (so that only one group at a time is authoritive for any given set of data).

  • It should be capable of protecting the users privacy. EvilBunny from SyndneyWireless has some interesting thoughts on the subject. See his [http://www.nodedb.com/ NodeDB] project for how he implements it.

  • It should be able to interact with the CaptivePortal software as both an authentication source and a node information source. See the MetaNet page for some ideas.

  • It should monitor nodes for usage metrics and availability and be able to present that information when people are searching for or viewing nodes.
  • It should encourage friendly competition between cities, neighborhoods and people. This could be down by breakding down usage metrics by node, neighborhood, city and state. Which neighborhood has the most nodes, the most reliable nodes, gets the most hours of usage a month? Which user has used the most nodes, the two nodes farthest apart, spent the most hours online (most hours online excluding their own node?). Which wireless group has the most nodes, the most active nodes, the most interested people, the highest churn, the most hours used etc. To encourage new groups or neighboorhods it could also measure the rate of growth a a metric.
  • It should require an email address to register a new node. On a regular basis it should require an ack to a nodes existance to keep the node data as fresh as possible.
  • A wiki module should be capable of pulling basic node data from the map server so that node data can be displayed in the wiki via the something like [[NodeData(351)]].

  • It should be able to display maps for single nodes or geographic regions.
  • It should use a projection (and ideally a data source like MapBlast) which will work world wide. Ideally it should be able to serve node data with different backends (street data, elevation data, topographical data etc).

  • It should be able to differentiate between different types of nodes (gateway, repeater, user) and of their status (active, broken, interested party).
  • It should be able to draw lines between nodes where connectivity exists and map out the logical network.
  • It sould be able to act as an IP management solution to allow node owners and the SpecialOps team to easily track and manage which nodes are supposed to belong to which networks.

  • It should be able to graph a coverage range of a node. Either based on a simple radio propagation metric (eg. in a city coverage is primarily down streets) or based on feedback (netstumbler data?) from gargoyles and users.


[CategorySoftware]

MapSoftwareDevel (last edited 2007-11-23 18:00:47 by localhost)