In spirit of open source and data openess it would be nice to see this project support map project that uses open source technology and open data - ​OpenStreetMap. OpenStreetMap if free (as in speech) alternative to Google Maps and maps can be create in combination with z ​OpenLayers javascript library.

In order to avoid a huge transfer of data ​Geojson could be used for the transfer of data points in the browser, and status updates without reload the entire page (once we have outgrown ​http://awmn.net).

Additional layer can also display aerial photos from Google Maps or Bing Maps server (in this case, the visible SSL warnings, so this should not be the default view)

This idea is quite old, he it became relevant with ​#217 because Google offers HTTPS requests only with payment not for free. But Google Maps v3 (which would be used in a new version can be accessed through HTTPS as well).

Non-profits and applications deemed in the public interest (as determined by Google at its discretion) are not subject to these usage limits.

In addition we recommend that eligible Non-profits apply for a Maps API Premier license through the Google Earth Outreach program. This provides a number of benefits, including the right to opt-out of advertising, higher quotas for Maps API web services, and technical support.

But probably this is only for USA non-profits.

And I would just wait until they contact us: ... a warning may be shown on your map and a Maps API Premier sales manager may contact you to discuss your licensing options.

We could definitely export data in a format compatible with it so that nodes can be seen there as well. Or mirror node data in CouchDB as a module in nodewatcher. But this they have a bit different goals than nodewatcher. Anyway, that would be a different ticket. Or we could have a module for nodewatcher using it to display a local map.

I don't know enough about Nodewatcher to understand what you mean by "they have a bit different goals than nodewatcher", but if you could work with libremap team and make it usable with nodewatcher than this seams to me like a nice fit, especially if everybody else will also be using it.

Libremap is something completely different. It is not a map widget, but it is a system based on CouchDB where nodes (or a system like nodewatcher) push information to a server (or a set of servers) that can then synchronize this database among themselves. Then a GUI can display all the collected information on a map. It is a very simple thing.

So yes, nodewatcher 3 can easily support a module that pushes this information to libremap. Implementing such a module should be fairly easy. But this has nothing to do with using OSM instead of Google Maps in nodewatcher itself.

And module could also embed a map so that you could have on nodewatcher a "global map" and "local map". But, on the other side, it is true that having too maps is a bit confusing. It would be useful that when you zoom in you see all links and so on, but if you zoom out and see the whole world, you could see all other nodes from all other networks as well. There are many ways how to do that. For example, having a layer being displayed from Libremap. Or we could even read ourselves data from there. On the other side, it would be interesting if we could reuse their codebase. But I do not think they support drawing links between nodes?

On the other side, it would be interesting if we could reuse their codebase.

Well, their codebase consists of a CouchDB server and everything is then handled client-side if I read the source code correctly (I did it really quick so I might be wrong). So, to include other stuff in our "global map" we just need to design this global map with hooks/API in mind, so another module can provide additional points on it.

And this additional module would then do a really simple CouchDB query to get all the nodes from LibreMap. Libremap is really simple.

I was thinking about client side code reuse. So how they draw nodes/do map. Maybe we could use their code and push our nodes into their map, rather than reimplementing drawing and then be pulling nodes into our map.

Technical:
We use a dedicated wildcard *.tile.openstreetmap.org certificate
signed by RapidSSL/GeoTrust on the 12 geo distributed cache servers.
The SSL termination is handled by nginx. SSL Report:​https://www.ssllabs.com/ssltest/analyze.html?d=a.tile.openstreetmap.org
Enabling SSL on tile is a step towards being able to offer HTTPS as an
option on openstreetmap.org for more than just the login page.

Nodewatcher v3 now uses Leaflet with OpenStreetMap in the node configuration editor. The next step is to create the global map module that displays all the nodes together with the topology on a single map.

Topology information will come from datastream (same as in #736) and there are two ways to obtain location information:

The location module may store the location into datastream (by registering a topology storage extension), which would also (later) enable view of node location changes through time (although this is rare).

Location information may be fetched from the database. In this case only the current information will be available.

The location module may store the location into datastream (by registering a topology storage extension), which would also (later) enable view of node location changes through time (although this is rare).

Would that be a separate datastream then? So a datastream for a location of a node? Wouldn't then we make a datastream for every configuration option as well and have it stored through time?

On the other hand, having location in would finally make mobile nodes really mobile and you could trace how they move. Or maybe if we don't want datastream for each configuration option, we could have location datastream only for mobile nodes?

BTW, maybe we should think about datastream being versioning for registry. So we store monitoring into registry, which we then copy into datastream. And why not do the same with configuration? Only that configuration we would make an entry only when configuration changes, not every time.

The question is: do we have a datastream for each value in configuration, or do we have one big datastream for all configuration.

I agree that other ideas are also possibilities, but in this case fetching data would require several API calls, querying for the values that were in effect at specific points in time. This would also enable inconsistent views on the data – also what happens when a node's streams are removed?

I agree that other ideas are also possibilities, but in this case fetching data would require several API calls, querying for the values that were in effect at specific points in time. This would also enable inconsistent views on the data – also what happens when a node's streams are removed?

I don't think there is anything much wrong with denormalizing data for common use cases. So having location and ETX in topology datastream together with having a separate datastream for ETX through time and location through time.

What I am saying is that we should have two ways to fetch data:

through a relation database you can make complicated queries and fetch latest data (monitoring and configuration and anything else)

through a NOSQL database you can make simple request for data and fetch any data in the past, and as it is common in NOSQL world, we denormalize sometimes for common cases, but in the worst case you have to make multiple queries and you might have to reconstruct a consistent view yourself (because in most cases slight inconsistencies will not matter)

Most modules will use only the former, but some modules currently will use the latter. And then we can have more specific or generic modules later on for the latter.

Ok, I believe that this second part should be moved into its own ticket and leave here only things related to the API that we will currently use for the map. Otherwise, I agree that there should be some kind of support for having historic view of configuration values.

The administration.location module registers an extension that creates markers for all nodes which have a location set. It also creates polylines for all topology links where their source and target have a location set.

The routing.olsr module registers an extension that changes the color of the polylines based on the stored ETX metrics of the links.