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.

OSM Volunteer
Coordinator, USBRS and California/Rail WikiProjects

Talk-us mailing list

Reply via email to