Differences between revisions 9 and 11 (spanning 2 versions)
Revision 9 as of 2002-06-20 15:13:54
Size: 5944
Editor: pw
Comment:
Revision 11 as of 2002-06-22 00:09:55
Size: 6610
Editor: user-uini6a1
Comment:
Deletions are marked like this. Additions are marked like this.
Line 7: Line 7:
=== Core Features === last used field (for nocat)
recent changes
email notification of changes
node audit view
make map data load directly from the client and use html layers to overlay node data (by passes usage restrictions?)
stand alone client (eg. boingo client)
Line 9: Line 14:
 * It should be able to display maps for single nodes or geographic regions.
 * It should be able to differentiate between different NodeTypes and their status.
 * 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.
 * Should be an API (HTTP, XML-RPC, SOAP ... whatever) for manipulating node data.
 * Any data storage schema (SQL?) should be as generic as possible to allow future ideas to be worked with. The schema should have a notion of users, nodes and usage metrics.
 * It should follow our principle of ZeroMaintenance. This means that where ever possible maintenance tasks should be automated or distributed to the user base.
 * It should be able to draw lines between nodes where connectivity exists and map out the logical network.
 * It should have the notion of owners and maintainers (tech contact) of nodes.
 * Group data should maybe include lots of things (name, lat/long boundries, url, contact person, list, report problem, cities (??), countries(?)).
 * Should have the notion of roles (eg. whois). Nodes don't have contact info they point to a person (so when you update your contact info, any nodes that you are associated with are updated at the same time).
 * [FUTURE] It should be able to make overlaid node data clearly visible over the maps (eg. by making the street level map grey scale and nodes color).
 * It should use a projection (and ideally a data source like MapBlast) which will work world wide.
 * [FUTURE] It should be have a modular mapping engine so it serve node data from multiple sources (street data, elevation data, topographical data etc).
 * [FUTURE] Should have the concept of an "area admin", people who can edit any node data in their area (most people should only be able to edit their own data).
 * [FUTURE] 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.
=== Guidelines ===
Line 25: Line 16:
=== Scaling Features ===  * [high] 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.
 * [high] Any data storage schema (SQL?) should be as generic as possible to allow future ideas to be worked with. The schema should have a notion of users, nodes and usage metrics.
 * [med] It should require as little maintenance as possible. As much as possible all maintenance tasks should be automated or distributed to the user base.
 * [med] It should have reporting tools which 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, has the best node uptime, 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.
 * [low] We've had a couple requests for internationalization for non-english speaking users. At least the ability to add this later without a complete rewrite would be a good thing.
 
=== Mapping Features ===
Line 27: Line 24:
 * 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.
 * 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.
 * [FUTURE] It should monitor nodes for usage metrics and availability and be able to present that information when people are searching for or viewing nodes.
 * [FUTURE] 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.
 * [FUTURE] 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). JasonLuther wrote a good [http://lists.personaltelco.net/pipermail/mapdev/2002q2/000059.html beginning] of an XML interchange format.
 * [FUTURE] 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)]]}}}.
 * [FUTURE] It should be able to store all the information about a node as [http://lists.personaltelco.net/pipermail/setup/2002q2/000830.html per request] by David Schargel.
 * [high] It should be able to display maps for single nodes or geographic regions.
 * [high] It should be able to differentiate between different NodeTypes and their status.
 * [high] It should use a projection (and ideally a data source like MapBlast) which will work world wide.
 * [med] It should be able to draw lines between nodes where connectivity exists and map out the logical network.
 * [med] It should be able to make overlaid node data clearly visible over the maps (eg. by making the street level map grey scale and nodes color).
 * [med] It should be have a modular mapping engine so it serve node data from multiple sources (street data, elevation data, topographical data etc).
 * [low] 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.
Line 35: Line 32:
=== Community Features === === Data Management Features ===
Line 37: Line 34:
 * It should be capable of protecting the users privacy. EvilBunny from [http://www.sydneywireless.com SydneyWireless] has some interesting thoughts on the subject. See his [http://www.nodedb.com/ NodeDB] project for how he implements it.
 * 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.
 * [high] Group data should maybe include lots of things (name, lat/long boundries, url, contact person, list, report problem, cities (??), countries(?)).
 * [high] Should be an API (HTTP, XML-RPC, SOAP ... whatever) for manipulating node data.
 * [med] 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.
 * [med] It should have the notion of owners and maintainers (tech contact) of nodes.
 * [med] 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 (my assumption is that this primarily requires an API to the info).
 * [med] It should be able to store all the information about a node as [http://lists.personaltelco.net/pipermail/setup/2002q2/000830.html per request] by David Schargel.
 * [low] Should have the notion of roles (eg. whois). Nodes don't have contact info they point to a person (so when you update your contact info, any nodes that you are associated with are updated at the same time).
 * [low] It should be capable of protecting the users privacy. EvilBunny from [http://www.sydneywireless.com SydneyWireless] has some interesting thoughts on the subject. See his [http://www.nodedb.com/ NodeDB] project for how he implements it.
 * [low] Should have the concept of an "area admin", people who can edit any node data in their area (most people should only be able to edit their own data).
 * [low] 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.
 * [low] It should monitor nodes (and/or allow nodes to publish info to it) for usage metrics and availability and be able to present that information when people are searching for or viewing nodes.
 * [low] 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). JasonLuther wrote a good [http://lists.personaltelco.net/pipermail/mapdev/2002q2/000059.html beginning] of an XML interchange format.
 * [low] 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)]]}}}.
Line 44: Line 52:

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

last used field (for nocat) recent changes email notification of changes node audit view make map data load directly from the client and use html layers to overlay node data (by passes usage restrictions?) stand alone client (eg. boingo client)

Guidelines

  • [high] 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.

  • [high] Any data storage schema (SQL?) should be as generic as possible to allow future ideas to be worked with. The schema should have a notion of users, nodes and usage metrics.
  • [med] It should require as little maintenance as possible. As much as possible all maintenance tasks should be automated or distributed to the user base.
  • [med] It should have reporting tools which 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, has the best node uptime, 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.
  • [low] We've had a couple requests for internationalization for non-english speaking users. At least the ability to add this later without a complete rewrite would be a good thing.

Mapping Features

  • [high] It should be able to display maps for single nodes or geographic regions.
  • [high] It should be able to differentiate between different NodeTypes and their status.

  • [high] It should use a projection (and ideally a data source like MapBlast) which will work world wide.

  • [med] It should be able to draw lines between nodes where connectivity exists and map out the logical network.
  • [med] It should be able to make overlaid node data clearly visible over the maps (eg. by making the street level map grey scale and nodes color).
  • [med] It should be have a modular mapping engine so it serve node data from multiple sources (street data, elevation data, topographical data etc).
  • [low] 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.

Data Management Features

  • [high] Group data should maybe include lots of things (name, lat/long boundries, url, contact person, list, report problem, cities (??), countries(?)).
  • [high] Should be an API (HTTP, XML-RPC, SOAP ... whatever) for manipulating node data.
  • [med] 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.
  • [med] It should have the notion of owners and maintainers (tech contact) of nodes.
  • [med] 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 (my assumption is that this primarily requires an API to the info).

  • [med] It should be able to store all the information about a node as [http://lists.personaltelco.net/pipermail/setup/2002q2/000830.html per request] by David Schargel.

  • [low] Should have the notion of roles (eg. whois). Nodes don't have contact info they point to a person (so when you update your contact info, any nodes that you are associated with are updated at the same time).
  • [low] It should be capable of protecting the users privacy. EvilBunny from [http://www.sydneywireless.com SydneyWireless] has some interesting thoughts on the subject. See his [http://www.nodedb.com/ NodeDB] project for how he implements it.

  • [low] Should have the concept of an "area admin", people who can edit any node data in their area (most people should only be able to edit their own data).
  • [low] 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.

  • [low] It should monitor nodes (and/or allow nodes to publish info to it) for usage metrics and availability and be able to present that information when people are searching for or viewing nodes.
  • [low] 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). JasonLuther wrote a good [http://lists.personaltelco.net/pipermail/mapdev/2002q2/000059.html beginning] of an XML interchange format.

  • [low] 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)]].

Requests and Comments

  • R.D. Hammond requests that node owners can stipulate what type of usage they are condoning (permenant connections, passer bys only etc).
    • While I respect the concept I think it's going to be very hard to enforce socially and a better solution is bandwidth restrictions / session limits via something like NoCatAuth. -- AdamShand


[CategorySoftware]

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