<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p><br>
</p>
<div class="moz-cite-prefix">On 23/09/2020 23:01, Paul Johnson
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAMPM96pxTFWjGaVBRMXs7q-HmETxr+o_DHZCEshScMx-wtwzrw@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="ltr">
<div dir="ltr"><br>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Wed, Sep 23, 2020 at 4:37
PM stevea <<a href="mailto:steveaOSM@softworkers.com"
moz-do-not-send="true">steveaOSM@softworkers.com</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">Paul Johnson <<a
href="mailto:baloo@ursamundi.org" target="_blank"
moz-do-not-send="true">baloo@ursamundi.org</a>> wrote:
<br>
</blockquote>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
> 2. Tagging route information on ways. It's about a
decade too long at this point for ref=* on a way to be
completely disconnected from the entity the tag applies to:
That's why route relations exist. Biggest problem child on
this at the moment: OSM's own tilesets. Let's drop
rendering for ref=* on ways and just render the route
relations already, this and multipolygons are why relations
came to exist in the first place.<br>
<br>
Yes, 100% agreement. I think this is simply pure inertia
(the kind that says "broken process") on the part of
renderers.<br>
<br>
Can anybody (renderer authors included, maybe even
especially) are welcome to offer reasons why "the old
machinery" remains in place? Are there legacy use cases
that remain unclear to the wider community? Please tell us
here, if so.<br>
</blockquote>
</div>
</div>
</blockquote>
<p>The US is unusual in that it doesn't have a single ref per
section of road. Most places in OSM map what they see on the
ground, and the current OSM Carto rendering works just fine for
them.</p>
<p><br>
</p>
<blockquote type="cite"
cite="mid:CAMPM96pxTFWjGaVBRMXs7q-HmETxr+o_DHZCEshScMx-wtwzrw@mail.gmail.com">
<div dir="ltr">
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
<br>
While I still find murky and mysterious exactly "how" to
effect change in renderers (who you gonna call?), </blockquote>
</div>
</div>
</blockquote>
<p>When it was clear that the direction of travel for OSM Carto
wasn't going to be useful t me I forked what was there at the time
and started going in a slightly different direction.<br>
</p>
<p><br>
</p>
<blockquote type="cite"
cite="mid:CAMPM96pxTFWjGaVBRMXs7q-HmETxr+o_DHZCEshScMx-wtwzrw@mail.gmail.com">
<div dir="ltr">
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">my two best efforts along
these lines are to "tag well" and "wiki well." (And that
can include a great deal of discussion and consensus
building on its own, no doubt). Eventually, (and I've
discovered it can take years), renderers do catch up.<br>
</blockquote>
<div><br>
</div>
<div>To be clear, I don't want to throw any humans under the
bus on this, since the Carto folks really do make an elegant
style for Mapnik. Though if this is a Mapnik issue that's
preventing this, maybe it's time to either fix Mapnik or
consider alternatives? <br>
</div>
</div>
</div>
</blockquote>
<p>It's not strictly a Mapnik problem. It's certainly possible to
render information from relations in Mapnik (I've done it, for
different sorts of relations, and written diary entries about
it). There are a couple of tricky bits* though:</p>
<ol>
<li>You'd need to derive the shields from the ref and the road
itself from the way, and you're going to get some edge cases
where they "don't seem to match".</li>
<li>I expect that it would be _really_ difficult to render refs
from relations in the one country where that's needed and refs
from ways in the other 190-odd. The OSM style is a global
style, and that means that local edge cases (which is what the
US is here) can't get the "special-case handling" that might be
nice.</li>
<li>The infrequency with which OSM data is loaded now means that
more has to be done "on the fly" rather than "at data load",
which somewhat limits the options for how to solve the problem.</li>
</ol>
<p>I'm actually surprised that someone associated with the OSM US
community hasn't created a proof-of-concept "good US road route
rendering" variant of the OSM Carto style on a live server that
people can use for reference (I'm guessing ongoing server costs
wouldn't be huge - a couple of $ a day at one of the cheaper
hosters). Of the issues above (1) you can ignore in a proof of
concept (or deal with some of the edge cases), (2) isn't an issue
if you're just rendering the US and (3) isn't a problem if you can
live with downtime at the occasional reload (or have two databases
- one live, one available to be reloaded if you can't).<br>
</p>
<p>Best Regards,</p>
<p>Andy</p>
<p>* I've deliberately simplified things here for legibility -
there's lots of discussion about these issues in OSM Carto's
github, and there are also osm2pgsql options available now (see
<a class="moz-txt-link-freetext" href="https://pavie.info/2020/03/09/openstreetmap-data-processing-osm2pgsql-flex/">https://pavie.info/2020/03/09/openstreetmap-data-processing-osm2pgsql-flex/</a>
) that weren't an option previously that may really help here.<br>
</p>
<p><br>
</p>
</body>
</html>