[Talk-us] Proposal: Drinking-water-specific photomapping website

[OSM Volunteer stevea]

Hi Joe:

I have added a lot of these nodes in California (Northern, Central and Southern) and even recognize a few of my own at wide zoom.  I agree there is much room for growth in this dataset.  These are pretty sparsely entered into California, even with my moderate effort to add these data.  Step right up!

It is excellent that you have spun up so much already-useful early work!  Consider on-the-ground trotting:  for example, following each and every bicycle route in California in OSM with an eye towards auditing/qa-ing all drinking water resources.  How will these data enter OSM?  Data entry can also be done in an armchair sense (even imagining about and thinking through these as a thought exercise can be useful) by those with, say, an accurate slew of nodes to add.  Or a determination to know "how sparse or complete ARE these data?"  Might you somehow monetize this eventually?  Is an end-goal to have a self-sustaining project?  It might take a lot of volunteer work, become a shiny data source, then stagnate, you wouldn't want that.

Consider creating a QR code printed on a sticker or flyer along a route (say, at a tourism=infosign or a pole if you have permission to post on it) linking to your Leaflet rendering for that specific area at an appropriate zoom level.  A cyclist enabled with a smartphone can stitch something basic together today.  This has been suggested for CycleNet in Santa Cruz County, which is just OpenCycleMap tiles at 37 North 122 West and zoom=12.  Easy.  You might put a link to OCM (at the same lat-long-zoom "now displayed") in your Leaflet code.  As this is a bicycle-oriented map, that seems sensible.

Future development/growth perhaps changes out the URL on distributed real-world QR Code stickers or richens up the back end of your web site so it can (should, will if you do it) do whatever clickables you implement (hours, fee=yes, etc.) on nodes and tags and photo display and the rest of what you intend to do.  You might also just think about QR codes as stickers on poles or info boards as an idea and imagine where it takes you.

"Traction" (as you put it) or growth and future development will move with your ability to nimbly change things (and grow them) and reply to users, their data contributions, further suggestions, your (and Leaflet's) technical abilities in a particular themed direction you (as editor/author/creator) take it by making decisions about what to include (display) and how.

Part of it is building a community of users that make it two-way (by contributing, as well as one-way:  looking and "consuming" the data without contributing).  Often, when somebody wants there to be a node where there isn't one, and wants to contribute these data, you don't have exactly their method for them to do that.  You might have a particular method implemented that works under particular circumstances, but you are missing a piece or two for that user.  Discover these (this can be difficult) and remedy them.

OSM doesn't store geotagged pixels if you are going there.  Sites like Mapillary do the storage of pixels in pictures and how those are associated with the methods they display map data in a particular way, a chunk of back-end web management.  You might like Mapillary's presentation style (GUI) and imitate it, you might improve upon it, you might go in a very different direction using neater and/or newer ideas or software.  What goes on here is a fair bit to bite off (let alone explain) but it certainly can be done.

Your data vetting process and user security are vague, yet it is good that you ask about them because if you are managing the users independent of OSM volunteers (who use our own credentials for entering geo data) then you must fully implement that in a complete and robust way on your site.  That's also ambitious yet doable.

Making a wiki page is an excellent idea.  Initially look at OSM's many other WIkiProjects and see if you can start with a small acorn using that structure, as many oaks have thusly grown.  A good wiki can describe syntax and semantics that avoid ambiguities, create harmony and foster consensus, track progress, add structure (sometimes with table entries) and generally build community.  Eventually you'll have folks who tap tap away at things in a let's-build-it-together kind of way, where you team lead with that kind of attitude.  Everybody involved throws some shoulder into a well-structured project because you built all the pieces to support them to do so.  A sort of organic growth results, so skipper that ship.

I could say more, that's plenty, so I'll stop here.

SteveA
California
OSM Volunteer
Coordinator, USBRS and California/Rail WikiProjects