[Talk-us] Proposal: Sunset ref=* on ways in, favor of relations

stevea steveaOSM at softworkers.com
Tue Nov 10 17:52:47 UTC 2015

Richard Welty wrote:
>  the key thing, i think, is that mappers have little motivation to
>  work on route relations if they don't actually get used by
>  anything.

This is so, so true.  Not just about route relations, but in the 
general sense of "crowdsourced data SHOULD become visible by at least 
one renderer" whether an amenity=cafe node on mapnik, a new bicycle 
route on OpenCycleMap, freshly-defined (and tagged) rail 
infrastructure on OpenRailwayMap, AND route relations.

Renderers must be rather tightly coupled to the data they display: 
it can be challenging for OSM to receive quality data without a 
decent renderer displaying those data.  The more quality renderers we 
have, specific to their subset of displayed data, the better our data 
will become -- with as many renderers as we care to develop.  OSM is 
multi-dimensional in this sense, and we can certainly walk and chew 
gum at the same time.

The point is that these "other" renderers provide this motivation for 
mappers interested in their specific subset of tagging, beyond what 
shows up on mapnik.  Sure, novice mappers get excited to see the 
reward of their newly-added cafe node "blossom" on mapnik within a 
minute (or a few) thanks to fast tiling.  And we who map bicycle 
routes or rail infrastructure have gotten used to waiting for the 
minor delays (hours, a few days) it might take for renderers specific 
to OUR data to display our recent edits.

But to encourage volunteer editors to crowdsource OTHER data 
(addresses, better route relations) into OSM, -- which do not now 
readily render -- a nearly fundamental requirement is for a renderer 
to display those results.  These can be comprehensively managed 
volunteer efforts (OpenCycleMap, OpenRailwayMap), they can be 
something like the ItoWorld renderings, they can be a "sandbox" 
renderer like what Phil mocked up for highway shields.  But to gin up 
a renderer and keep it functioning, fed and cared for shouldn't be so 
difficult or mysterious.  Our national chapter (OSM-US) might take 
some initiative here, or it might coordinate parceling out such 
efforts to interested regional parties.  Let's both discuss and 
better manage these efforts.

Anybody up for writing a quick-and-dirty "here's how to develop an 
OSM renderer from scratch" wiki?  (Maybe I just haven't seen this if 
it already exists).  It may not be drop-dead easy, but an 
intermediate coder should be able to make one in short order (weeks, 
not months).


More information about the Talk-us mailing list