[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).
SteveA
California
More information about the Talk-us
mailing list