<!doctype html public "-//W3C//DTD W3 HTML//EN">
<html><head><style type="text/css"><!--
blockquote, dl, ul, ol, li { padding-top: 0 ; padding-bottom: 0 }
 --></style><title>Re: [Talk-us] Proposal: Sunset ref=* on ways in,
favor of</title></head><body>
<blockquote type="cite" cite>On Wed, Nov 11, 2015 at 7:55 AM, Richard
Welty <<a
href="mailto:rwelty@averillpark.net">rwelty@averillpark.net</a>>
wrote:
<blockquote>and for unsigned routes, either don't create the relation,
or create a</blockquote>
<blockquote>relation and use unsigned_ref instead of ref</blockquote>
</blockquote>
<div><br></div>
<div>And Paul Johnson <baloo@ursamundi.org> replied</div>
<div><br></div>
<blockquote type="cite" cite>I'm a proponent of preserving this data
in unsigned_ref=* myself...</blockquote>
<div><br></div>
<div>+1.  Please promulgate data so OSM does not LOSE or MISS
route relation data if there is no sign, let's CAPTURE them with
unsigned_ref=* if/as/when we can.  People might throw rocks at me
for saying this, but when/as we get to decent shield rendering, my
personal belief (contrary to Richard) is that unsigned_ref should
render with admin-level appropriate shields, rather than NOT render
because they are unsigned.  (We are talking about US-centric
highway shield rendering renderers).  I don't think I'm alone
here.  While "OSM purity" (via our "on the ground
observable" tenet) might lean in Richard's direction, a data
consumer looking for the right highway to travel on very likely wants
to see a shield on a road map, even if it doesn't show up on a
signpost on the road.  In the interests of publishing a more
useful product better tailored to this specific data consumer, we can
cut ourselves a little slack here by rendering an unsigned_ref=* as a
shield.</div>
<div><br></div>
<div>I very much like these encouraging indications on this
thread:</div>
<div><br></div>
<div>1)  Kevin Kenny <kennydb@acm.org> shared his
"catskills" hiking-appropriate renderer,</div>
<div><br></div>
<div>2)  Paul points out that cycle and bus route relations
already render with "OSM trade dress" renderers (those
available from the Main Page),</div>
<div><br></div>
<div>3)  Paul Norman <<a
href="mailto:penorman@mac.com">penorman@mac.com</a>> wrote Phil!
Gold's demo is "an excellent proof of concept" (I agree) but
it needs patching (or must use a modified Mapnik) to modify one or
more read-write database calls to become read-only, AND it appears to
remain needing to be ported to the new Carto stylesheets.  Much
has been written in github's openstreetmap-carto/issues/508 and
openstreetmap-carto/issues/596 about this, though with much being left
unresolved or difficult to currently resolve.  These are
promising developments, but there are serious technical hurdles. 
I offer a genuine tip of my hat to excellent discussion on these
github discussion threads.</div>
<div><br></div>
<div>4)  Richard writes (and others seem to concur) that Phil!'s
demo does federal and state level shields well enough, but leaves
county and city routes incomplete.  I find this a satisfactory
place to accept a preliminary implementation, with lower admin-level
(county and city) shields being completed over a longer time frame. 
(Tough nuts take longer to crack).</div>
<div><br></div>
<div>Especially to the dozen-or-more core people who really know what
you are talking about (you know who you are, alas, I am not one of
them), please let the good discussion momentum about rendering shields
(at least in the US) continue.  OSM as a project seems to have a
fierce determination do this (and do it right and well), but only as
much hard work and toolchain development continue.</div>
<div><br></div>
<div>SteveA</div>
<div>California</div>
</body>
</html>