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

Adam Franco adamfranco at gmail.com
Tue Nov 10 19:47:51 UTC 2015


>
> 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 <steveaOSM at softworkers.com> 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
> Talk-us at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-us
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/talk-us/attachments/20151110/f3e69cec/attachment.html>


More information about the Talk-us mailing list