As I see it you need three key things: a way for your colleagues to input and remove locations, a way to store that list of locations, and a way to show them as pins on a map. The latter is...
As I see it you need three key things: a way for your colleagues to input and remove locations, a way to store that list of locations, and a way to show them as pins on a map.
The latter is probably the most clear-cut: Leaflet with OpenStreetMap tiles is free, well established, and handles stuff like this as its absolute bread and butter. Mapbox, Cesium, ArcGIS and others do similar jobs with varying commercial plans, but I get the impression you were looking for something more DIY? There are other options out there for more specialist needs (d3 map visualisations can be incredibly powerful, for example), but probably more effort for a less useful result in this case.
Storage comes down to a choice between a proper database or just maintaining and updating a single GeoJSON file somewhere. This is going to depend a lot on how many work sites you're tracking, how robust this system needs to be, how much setup and overhead you're willing to take on, etc. - my impression is relatively small data volume (double digit number of sites?) and that low overhead as a priority, so may be easiest to just stick to a flat file for the sake of minimal moving parts. Tradeoff there is a higher chance of someone breaking the whole thing by missing a comma!
Input is going to depend heavily on what your team are familiar with - even though they aren't explicitly technical, it sounds like they'd be potentially happy enough working with raw coordinates (i.e. no need for predictive address lookup etc.) and maybe even maintaining a JSON file directly? If not, there are definitely options in terms of editing software and/or building a custom browser UI, which could be as simple as a couple of text boxes, but again adds more potential for maintenance headaches down the line.
On all of the above, there are tradeoffs of secrecy, reliability, and cost - I'm assuming the data is internal but not super sensitive, simplicity is more important than bulletproof uptime, and cost needs to be as close to zero as possible - but if any of these are way off the mark then let me know.
All of that in mind, I'm going to make a slightly unorthodox suggestion: set up a GitHub repo, just put the GeoJSON file and maybe a README in the root, and train your colleagues to edit and commit changes to the JSON file using the in-browser text editor. I'd never expect a non-techie to use the command line or understand git in depth, but I've had good success in the past teaching people to use it for markdown docs - just have them commit straight to main and they'll understand it as a linear edit history; devs might look down their nose at that model, but it's already leaps and bounds ahead of a totally untracked history on a hard drive or network share somewhere.
It's far, far from the neatest solution, but it's dirt cheap, comes with hosting and leaflet visualisation out of the box, inherently has change tracking and rollback for errors, handles authentication for you, allows multiple users to contribute from on- and off-site, and requires literally zero maintenance. In terms of display, it's as simple as logging into GitHub on whatever machine drives the big screen and maximising the window.
There are definitely other more "professional" solutions, and I'll happily discuss them, but you'd need to be careful about training your replacement or they'll succumb to entropy in 6-12 months when the first unexpected failure occurs.
Trunk-based development is a fine mechanism for small, coordinated teams. You teach how to pull before commits and push after, problem solved. That said, everyone doing this with only a single...
devs might look down their nose at that model
Trunk-based development is a fine mechanism for small, coordinated teams. You teach how to pull before commits and push after, problem solved.
That said, everyone doing this with only a single file is a recipie for needing to deal with merge conflicts. I'd probably create an 'import' folder where users can just add an arbitrary json file, then have a build process that gloms all the files in that folder together.
The good news is that the GitHub web editor won't allow you to create a conflict at all - that plus the fact it gives you a live preview to confirm the map looks as expected before saving are what...
The good news is that the GitHub web editor won't allow you to create a conflict at all - that plus the fact it gives you a live preview to confirm the map looks as expected before saving are what nudged me in that direction even though it's not necessarily optimal in other ways, in fact!
Either way, you're absolutely right that this'll only stick if it brings high enough utility with low enough effort; the GitHub web option definitely optimises for absolute minimal (dare I say zero?) effort in terms of things to maintain or fail in unexpected ways at a later date, at the expense of a day-to-day workflow that's a clunkier and has a higher learning curve.
If you're maintaining anything in house - build process or otherwise - then I'd totally agree with your post below: skip the JSON entirely and just use a simple web interface, it'll be far more user friendly. You're probably more likely to get buy-in up front if it's easier, but there's more potential for something to go wrong later in a way that might be difficult to diagnose for whoever's taken on the project a year down the line. Open question about which is the lesser of two evils in this situation!
This seems like the kind of project that will live and die by whether people consider it useful enough to keep it updated. The best bet would probably be a dead-simple website leveraging the tools...
This seems like the kind of project that will live and die by whether people consider it useful enough to keep it updated.
The best bet would probably be a dead-simple website leveraging the tools @Greg mentioned that provides a quick form to submit needed info, and a simple map page to load up on a big screen.
As I see it you need three key things: a way for your colleagues to input and remove locations, a way to store that list of locations, and a way to show them as pins on a map.
The latter is probably the most clear-cut: Leaflet with OpenStreetMap tiles is free, well established, and handles stuff like this as its absolute bread and butter. Mapbox, Cesium, ArcGIS and others do similar jobs with varying commercial plans, but I get the impression you were looking for something more DIY? There are other options out there for more specialist needs (d3 map visualisations can be incredibly powerful, for example), but probably more effort for a less useful result in this case.
Storage comes down to a choice between a proper database or just maintaining and updating a single GeoJSON file somewhere. This is going to depend a lot on how many work sites you're tracking, how robust this system needs to be, how much setup and overhead you're willing to take on, etc. - my impression is relatively small data volume (double digit number of sites?) and that low overhead as a priority, so may be easiest to just stick to a flat file for the sake of minimal moving parts. Tradeoff there is a higher chance of someone breaking the whole thing by missing a comma!
Input is going to depend heavily on what your team are familiar with - even though they aren't explicitly technical, it sounds like they'd be potentially happy enough working with raw coordinates (i.e. no need for predictive address lookup etc.) and maybe even maintaining a JSON file directly? If not, there are definitely options in terms of editing software and/or building a custom browser UI, which could be as simple as a couple of text boxes, but again adds more potential for maintenance headaches down the line.
On all of the above, there are tradeoffs of secrecy, reliability, and cost - I'm assuming the data is internal but not super sensitive, simplicity is more important than bulletproof uptime, and cost needs to be as close to zero as possible - but if any of these are way off the mark then let me know.
All of that in mind, I'm going to make a slightly unorthodox suggestion: set up a GitHub repo, just put the GeoJSON file and maybe a README in the root, and train your colleagues to edit and commit changes to the JSON file using the in-browser text editor. I'd never expect a non-techie to use the command line or understand git in depth, but I've had good success in the past teaching people to use it for markdown docs - just have them commit straight to main and they'll understand it as a linear edit history; devs might look down their nose at that model, but it's already leaps and bounds ahead of a totally untracked history on a hard drive or network share somewhere.
It's far, far from the neatest solution, but it's dirt cheap, comes with hosting and leaflet visualisation out of the box, inherently has change tracking and rollback for errors, handles authentication for you, allows multiple users to contribute from on- and off-site, and requires literally zero maintenance. In terms of display, it's as simple as logging into GitHub on whatever machine drives the big screen and maximising the window.
There are definitely other more "professional" solutions, and I'll happily discuss them, but you'd need to be careful about training your replacement or they'll succumb to entropy in 6-12 months when the first unexpected failure occurs.
Trunk-based development is a fine mechanism for small, coordinated teams. You teach how to pull before commits and push after, problem solved.
That said, everyone doing this with only a single file is a recipie for needing to deal with merge conflicts. I'd probably create an 'import' folder where users can just add an arbitrary json file, then have a build process that gloms all the files in that folder together.
The good news is that the GitHub web editor won't allow you to create a conflict at all - that plus the fact it gives you a live preview to confirm the map looks as expected before saving are what nudged me in that direction even though it's not necessarily optimal in other ways, in fact!
Either way, you're absolutely right that this'll only stick if it brings high enough utility with low enough effort; the GitHub web option definitely optimises for absolute minimal (dare I say zero?) effort in terms of things to maintain or fail in unexpected ways at a later date, at the expense of a day-to-day workflow that's a clunkier and has a higher learning curve.
If you're maintaining anything in house - build process or otherwise - then I'd totally agree with your post below: skip the JSON entirely and just use a simple web interface, it'll be far more user friendly. You're probably more likely to get buy-in up front if it's easier, but there's more potential for something to go wrong later in a way that might be difficult to diagnose for whoever's taken on the project a year down the line. Open question about which is the lesser of two evils in this situation!
This seems like the kind of project that will live and die by whether people consider it useful enough to keep it updated.
The best bet would probably be a dead-simple website leveraging the tools @Greg mentioned that provides a quick form to submit needed info, and a simple map page to load up on a big screen.