<html>

  <head>

    <meta content="text/html; charset=ISO-8859-1"

      http-equiv="Content-Type">

  </head>

  <body text="#000000" bgcolor="#FFFFFF">

    <br>

    <div class="moz-cite-prefix">On 2014-04-20 21:45, Tom Hayward wrote:<br>

    </div>

    <blockquote

cite="mid:CAFXO5Z1+NnLksnaK8YUGSmtn6gxrJAFOq9Hs3X3_PY=i9q5xyg@mail.gmail.com"

      type="cite">

      <pre wrap="">On Sun, Apr 20, 2014 at 5:51 PM, Dean Gibson AE7Q <a class="moz-txt-link-rfc2396E" href="mailto:hamwan@ae7q.com"><hamwan@ae7q.com></a> wrote:

</pre>

      <blockquote type="cite">

        <pre wrap="">Actually, what would be helpful (and motivate sharing of dynamic data), is for the text in those "click-on bubbles" for each site to indicate the "type" of data.  Eg (these are just ideas;  some of them are mutually exclusive):

Site survey 2013-06-07

Static report 2014-02-14

Dynamic report 2014-04-02 16:53Z

Online; status at 2014-04-20 17:37Z

Offline; last online 2014-04-19 02:15Z

</pre>

      </blockquote>

      <pre wrap="">

Dean,

I agree the map data could use more verbosity. These are the current types of map data:

- Coverage (the red overlay)

- Site (the radiation symbol)

- Link (PtP between sites)

- Client

- Site survey (non-live client data)

All data are online/live unless labeled "site survey". Online nodes are represented by blue lines where the line width is related to the current negotiated link speed (this fluctuates a bit). When a client drops offline, the link line disappears and the signal strength shows "null dBm"--essentially no special handling in the software, the value just goes away. Signal surveys are gray lines, indicating a tested path but no connection.

The data is collected with SNMP into Cacti, then aggregated into a JSON file for the website. Javascript parses the JSON file and places the data on the map. I've been working on a portal website to allow people like you to edit DNS entries and edge firewall rules for your hosts. Eventually, I'll consolidate the map data into this database so you can update things like lat/lon yourself. Then I'll clean up the JSON a bit, and finally clean up the javascript that generates the map. If you'd like to jumpstart integration of your suggested changes into the map, you can start work on the javascript while I finish up the back end. Just click View Source on hamwan.org and you should have everything you need.

Tom KD7LXL

</pre>

    </blockquote>

    <br>

    Questions (I've briefly looked at the JavaScript):<br>

    <br>

    <ol>

      <li>How often is the SNMP data from clients collected?</li>

      <li>Is the data in a "client bubble" dynamic in the sense of

        refreshing every time a client location is clicked, or is a page

        refresh needed for a data update?</li>

      <li>If the latter, I'm curious as to why we are using client-side

        (eg, JavaScript) rather than server-side (eg, php) processing. 

        I use Google Maps on a couple of my web pages, and it works well

        with php.</li>

      <li>Do you have to make a change to your database when SNMP data

        from a site comes online?  I enabled SNMP data yesterday, but

        see no change in my listing.</li>

    </ol>

    I would think that the best way to handle sites would be to treat

    everyone the same, and list SNMP data when available, on a dynamic

    basis.  What would be nice in the data, is (as I hinted above) the

    date/time of the last signal strength, and of course its value.  I'd

    think displaying the last signal value, even if months old, would be

    useful.  From what I see of the JavaScript, that data is currently

    not available.<br>

    <br>

  </body>

</html>