> > 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).
I would love to volunteer to test and validate any instructions that folks are able to write as well as provide editing and feedback. I wrote and maintain a project called Curvature <http://www.adamfranco.com/2012/12/05/curvature-py/> 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 (like this example <http://www2.adamfranco.com/curvature/kml/north_america/us/vermont.surfaces.kml>) but the tool-chain is a bit too long and updates are too delayed for broad usage by the public. Best, Adam On Tue, Nov 10, 2015 at 12:52 PM, stevea <[email protected]> wrote: > 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 > > > _______________________________________________ > Talk-us mailing list > [email protected] > https://lists.openstreetmap.org/listinfo/talk-us >
_______________________________________________ Talk-us mailing list [email protected] https://lists.openstreetmap.org/listinfo/talk-us
