<div dir="ltr"><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote">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).</blockquote><div><br></div><div>I would love to volunteer to test and validate any instructions that folks are able to write as well as provide editing and feedback. <br><br></div><div class="gmail_extra">I wrote and maintain a project called <a href="http://www.adamfranco.com/2012/12/05/curvature-py/" target="_blank">Curvature</a> that analyses the geometry of highways in the OSM data set and outputs overlays that motorcyclists and others can use to find the most twisty roads to ride/drive. One of the biggest hurdles to this project has been the lack of highway-surface data in most of the US and I'd love to put together a renderer that colors highways based on their surface=* tags, highlighting those that are missing the tag. I've been generating this data for myself as KML files (<a href="http://www2.adamfranco.com/curvature/kml/north_america/us/vermont.surfaces.kml">like this example</a>) but the tool-chain is a bit too long and updates are too delayed for broad usage by the public.<br clear="all"><div><div><div dir="ltr"><br>Best,</div></div></div>
Adam<br><br></div><div class="gmail_extra"><div class="gmail_quote">On Tue, Nov 10, 2015 at 12:52 PM, stevea <span dir="ltr"><<a href="mailto:steveaOSM@softworkers.com" target="_blank">steveaOSM@softworkers.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>Richard Welty wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
 the key thing, i think, is that mappers have little motivation to<br>
 work on route relations if they don't actually get used by<br>
 anything.<br>
</blockquote>
<br></span>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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).<span><font color="#888888"><br>
<br>
SteveA<br>
California</font></span><div><div><br>
<br>
_______________________________________________<br>
Talk-us mailing list<br>
<a href="mailto:Talk-us@openstreetmap.org" target="_blank">Talk-us@openstreetmap.org</a><br>
<a href="https://lists.openstreetmap.org/listinfo/talk-us" rel="noreferrer" target="_blank">https://lists.openstreetmap.org/listinfo/talk-us</a><br>
</div></div></blockquote></div><br></div></div>