Edit "MapSoftwareDevel" - Personal Telco Project

Name our soccer team

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

=== General 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.
 * [high] There should be a way to monitor changes / additions / deletions.  Either with something like RecentChanges or email notification.  Ideally there would be some way to break it up into areas (so Portland only see's Portland changes etc).
 * [high] It should be possible for one installation to host maps for multiple groups (like our current map server).
 * [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.
 * [low] A view where you can get a list of all then nodes on one page (small map, address etc)  for printing while doing drive by node audits.

=== 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] Maybe make map data load directly from the client and use HTML layers to overlay node data (and their by not break MapBlast usage guidlines?)
 * [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.
 * [low] A standalone Windows/Mac/Unix client which could download all the node data to the PC for finding nodes when you don't have internet.  Ideally it would be syncable like the IPass client and could hook to a GPS.

=== 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), one fairly key one is that a portal should be able to publish a timestamp to the map software everytime someone sucessfully authenticates (as this is the best form of monitoring they have)
 * [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] 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] 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] 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] 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]

Comment:

Add to: Trivial change Remove trailing whitespace from each line

Emphasis: ''italics''; '''bold'''; '''''bold italics'''''; ''mixed '''bold''' and italics''; ---- horizontal rule.
Headings: = Title 1 =; == Title 2 ==; === Title 3 ===; ==== Title 4 ====; ===== Title 5 =====.
Lists: space and one of: * bullets; 1., a., A., i., I. numbered items; 1.#n start numbering at n; space alone indents.
Links: JoinCapitalizedWords; [[target|linktext]].
Tables: || cell text |||| cell text spanning 2 columns ||; no trailing white space allowed after tables or titles.

For more help, see HelpOnEditing or HelpOnMoinWikiSyntax.