meshmap issueshttps://gitlab.kg6wxc.net/mesh/meshmap/-/issues2023-01-09T00:10:01Zhttps://gitlab.kg6wxc.net/mesh/meshmap/-/issues/25Feature request: KML or GeoJSON support2023-01-09T00:10:01ZJen HertingFeature request: KML or GeoJSON support2 reasons/use cases:
1. We have multiple meshmap servers on our mesh and keeping the non-mesh markers synced between the servers has become somewhat of a bear. Currently, I've broken out the import CSV script so that it can be called vi...2 reasons/use cases:
1. We have multiple meshmap servers on our mesh and keeping the non-mesh markers synced between the servers has become somewhat of a bear. Currently, I've broken out the import CSV script so that it can be called via command line, pushing out a CSV via ansible, and importing the CSV using that script. I'd much prefer to have a bunch of static files (KML or GeoJSON), hosted on a server (obviously could be the same as the meshmap server), and let the client's web browser pull the marker locations in from there.
2. This also allows for some amount of dynamic non-mesh markers: unit tracking via APRS, dynamic descriptions for markers that have weather stations, etc.
Stretch goal: supporting polygons for things like NWS Alerts.https://gitlab.kg6wxc.net/mesh/meshmap/-/issues/24Feature request - Hide connection lines between nodes that are filtered out2021-08-20T02:09:46ZBill KreutingerFeature request - Hide connection lines between nodes that are filtered outHiding connection lines between nodes that are filtered out can help show which frequency bands are most depended on in different regions. I thought of this while drafting an email to my congressman's office asking for them to intervene ...Hiding connection lines between nodes that are filtered out can help show which frequency bands are most depended on in different regions. I thought of this while drafting an email to my congressman's office asking for them to intervene for us on the FCC's recent rules change on the 5GHz bandEric - kg6wxcEric - kg6wxchttps://gitlab.kg6wxc.net/mesh/meshmap/-/issues/21Discussion: Proposing some changes to the 'node_info' table2020-08-01T20:54:58ZScott - KI7ONKDiscussion: Proposing some changes to the 'node_info' tableI started working on an implementation of the network mapper/crawler in Python because I thought `asyncio` would be an easy way to speed up the polling of the network (and I'm much more familiar with Python): [pyMeshMap](https://gitlab.c...I started working on an implementation of the network mapper/crawler in Python because I thought `asyncio` would be an easy way to speed up the polling of the network (and I'm much more familiar with Python): [pyMeshMap](https://gitlab.com/smsearcy/pymeshmap)
Coming it at from the mapping side there are a few changes to the database that I think would make this more efficient (and easier to write). Granted, I've only dug into the mapping side so I don't know the repercussions to the rest of the application. It basically comes down to a few changes:
1. Use the *wlan_ip* as the primary key.
2. Replace the *removed_nodes* table with a *node_status* column in *node_info* that is used to track a node's status (for example: "active", "inactive", and "gone").
3. Move manually set locations to another table.
## Mapping Process
For context, here's how I intend the node mapping process:
1. Expire the *hosts_ignore* table based on age of entries.
2. Get a collection of IPs to ignore (preferably a hashed collection for fast lookups, I'm using Python's `set` collection).
3. Run the poller, providing it a "starting" node for OLSR and the IPs to ignore and getting back data for all the nodes it could poll and any errors.
4. Loop through the nodes, adding/updating the database.
5. Add ignore entries for any errors
6. Run a query to update node statuses based on time since last seen.
## Rationale
I suggest the primary key change because the IP address needs to be unique on the network so it would be a natural primary key. Furthermore, it's how the nodes are referenced when looking up the location information to build the topology information, so having it as a key value should be a performance increase in larger networks (although that depends on specific database implementations). Another benefit is that would eliminate the need for additional/separate queries to handle the majority of node renames (the exception being if someone changed the IP address as well, so the question is how important that edge case is).
Consolidating the node tables would mean that there was no longer a need to check if a node had been deleted and then deleting the row from the one table and adding it to the other one. A single update with the current timestamp and an "active" status would return a node to active status. It would require updating queries that select the nodes to display so that non-active nodes are excluded. I haven't looked into how many places that would be.
Similarly, moving manually set locations to a separate table would eliminate another "check" in the import process, although it would complicate the location lookup, both for updating topology and placing on the map. Thus the more I think about this one I'm less sold on it. It would have the advantage of always having the node's location in *node_info* so that if someone did enter the location we'd be able to see that value.
While the goal of several of these is to reduce database calls, I'm not sure the actual performance impact of all of them, so I was also considering the simplicity of the code. And some of that is impacted by the tools I'm using in Python. For instance, the SQLAlchemy ORM has a convenient method to handle the INSERT/UPDATE by just calling `dbsession.merge(new_model)`.https://gitlab.kg6wxc.net/mesh/meshmap/-/issues/20Capture errors2020-07-03T05:00:19ZEric - kg6wxcCapture errorsNeed to capture errors from the polling scripts (and maybe other php files) and display them on the admin interface at the least.
Yet another reason for some kind of notifications or alerts.
Someone needs to do a re-write! :confounded:Need to capture errors from the polling scripts (and maybe other php files) and display them on the admin interface at the least.
Yet another reason for some kind of notifications or alerts.
Someone needs to do a re-write! :confounded:https://gitlab.kg6wxc.net/mesh/meshmap/-/issues/3Centralized map server needed2020-06-24T04:28:19ZEric - kg6wxcCentralized map server needed> (Originally Issue #13 opened by Orv Beach @w6bi)
Create a centralized "master" mapper instance, available from the Internet, that doesn't poll nodes but rather accepts and displays mapper databases from other "client" mapper instan...> (Originally Issue #13 opened by Orv Beach @w6bi)
Create a centralized "master" mapper instance, available from the Internet, that doesn't poll nodes but rather accepts and displays mapper databases from other "client" mapper instances. The master should provide :
* A list of contributing mapper instances, including:
* Client mapper Hostname
* Geographical location of client database
* The last time the client mapper uploaded to master
* Map tiles as appropriate for contributed data.
* A facility for automated uploads from contributing client mappers.
Additionally a facility should be made available to the clients to easily extract and submit data to the master, and should be capable of being run in a cron job.Eric - kg6wxcEric - kg6wxc