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.
Coordinator, USBRS and California/Rail WikiProjects
Talk-us mailing list