Re: [Talk-us] ref=* tags on links (Kevin Kenny)

[OSM Volunteer stevea]

So many conversations at once; this list-digest medium proves limiting at 
times, even often.

Helpful old-fashioned aids here might be sketch boards where small-group (two, 
three people?) sub-projects can spin out and a main thread group where someone 
explains what s/he sees going on and how we might all get on the same page, 
making (actually or the equivalent of) a two- or three-page (at most?) wiki / 
OSM structure with two or three graphics of stacks of things, where this stack 
differs from that stack, where technical boundaries make divergences among 
real-world data consumers and a shortest path to "let's help each other out to 
learn how to make this very difficult bubble gum chewable by everybody around 
here who needs to."  Yes, that's a rather tall order yet we can get there.  
Otherwise I might conclude we have some communication difficulties we'll need 
to solve sooner.  We have pieces of this scattered among us in stovepipes.  
That's all, it isn't terrible, it is solvable.

OSM stacks and data consumers (especially over time, years, as projects evolve, 
needs change, specification revise, tagging syntax meets renderer and "changing 
taste among data consumers is both well anticipated and poorly anticipated."  
These are highly complex. the system is a global mapping project among millions 
of us for billions of us, it is largely volunteer and partly "on a shoestring 
and even amongst ourselves we don't always share data and process in our 
stovepipes without a certain reticence .  There is such a thing as intellectual 
property, trade secrets and what we are talking about doing, process 
improvement, pays truly huge dividends for our future.

Let's be the best project we can be.  We're a lot of very smart people.  We can 
solve in weeks or months or a year what it might have taken us ten years (or 
15) to get to "about here."  I'd say we're doing fine, even as we do have some 
climbing ahead.  OK, I'm fine with that.  I'm being a bit rough and fast here, 
no doubt this will morph.  Good.

SteveA
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] ref=* tags on links

[Kevin Kenny]

On Fri, Aug 24, 2018, 3:46 PM Paul Johnson  wrote:

>
>
> On Fri, Aug 24, 2018, 14:33 Richard Welty  wrote:
>
>> On 8/24/18 3:15 PM, Paul Johnson wrote:
>> > This is a criticism I've had about the Standard renderer for a while
>> > now.  Andy Allan's rendering refs from relations.  Osmand is rendering
>> > refs from relations.  Magic Earth is rendering refs from relations.
>> > Pretty sure Mapbox and Rand McNally are as well.
>> "don't tag for the renderer" - but we lose sight of the fact that there
>> are
>> multiple renderers, and non-renderer data consumers on top of that.
>>
>
> And?
>
> It's been obvious for about a decade now that this exact thing was going
> to happen, let's make it happen already.
>

I'm trying to do *my* part, with a worked example of *how* to render
shields from route relations, what needs to happen with the front
(OSM->database) end of the render stack (or a data analysis stack, for that
matter), why my example of that will not scale to a planet with minutely
diffs, and a sketch of how to fix that.

That's why my discussion brings on TL;DR. It gets a bit (no, a lot!) bogged
down in the PostGIS details, but details are important.

As I said, I'm still having technical difficulties with mailing to
tile-serving, so thus far Senpai has not noticed me.

>
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Shaped highway shields - trying to revive

[Kevin Kenny]

I'm trying to get them involved, but tile-serving rejects my mails. There's
someone on the server admin team looking into it, but no luck yet. There
may have been further progress today, but I've been out hiking and only
just got back to my email. I'm not yet to the bottom of my inbox.

On Fri, Aug 24, 2018, 2:27 PM Martijn van Exel  wrote:

> Agreed. I think it's really nice to have active thinking and work around
> this. The key is to get the rendering stack people involved. Perhaps Paul
> Norman can function as a liaison?
>
> Martijn
>
> Sent from my iPhone
>
> On Aug 24, 2018, at 12:06, Evin Fairchild  wrote:
>
> Really glad to see that someone is reviving this and actually taking the
> step to get it rendered. Frankly, I never understood why Phil didn't do
> this in the first place. I even mentioned this to him at the time (can't
> remember his response though).
>
> -Evin (compdude)
>
> On Wed, Aug 22, 2018, 2:21 PM Kevin Kenny  wrote:
>
>> (I apologize in advance to the tile-serving community if this message
>> is inappropriate. I see that traffic on that list is largely limited
>> to highly specific technical discussions, but couldn't see a more
>> appropriate forum.)
>>
>> For several years now, I've been using the support code for shaped
>> shields in OSM, originally developed by Phil! Gold and Richard Weait,
>> to render North American-style maps. A typical example can be found at
>> https://kbk.is-a-geek.net/catskills/test4.html?la=41.4143=-74.4233=14
>> In that view, you can see distinct shields for Interstate, US, New
>> York, and county routes, and at least one concurrence (New York 17M
>> aligned with US 6). Incidentally, Phil's is the only renderer that
>> I've seen that can make sense of cases like West Virginia's bizarre
>> double route numbers, as seen in
>> https://kbk.is-a-geek.net/catskills/test4.html?la=41.4143=-74.4233=14
>> .
>>
>> The visual distinction among highway shields is really necessary in
>> North America, where there are so many different route networks
>> overlaid.
>>
>> In the course of working with the code, I've made a number of changes
>> and become seriously out of sync with the main development line, which
>> appears to be moribund. (Phil! and Richard have not answered recent
>> queries; I suspect that I have obsolete contact information, but the
>> messages also have not been returned undelivered.)
>>
>> Accordingly, I've (quite reluctantly) created my own repository -
>> https://github.com/kennykb/osm-shields - with material from the
>> project. The shield templates to be found there are mostly those of
>> Phil! (I added only a handful), but the code to manage shields is
>> almost entirely new. Some significant changes are:
>>
>> The list of shields to be rendered is obtained from the database
>> itself, rather than being predetermined by a configuration file for
>> each network. This has the disadvantage that refs that are known to be
>> problematic may be rendered (but in most cases they ought to be
>> unsigned_ref). On the other hand, it has the distinct advantage that
>> as mappers continue to create the route relations, the corresponding
>> shields appear virtually automatically.
>>
>> The composition of shield clusters, rather than being handled by a
>> stored procedure in the database, is done using a GroupSymbolizer in
>> Mapnik. I suspect, given the dearth of discussion that I find in a
>> Google query, that I'm the first user to attempt to use
>> GroupSymbolizer with actual open-ended shield clusters, and therefore
>> that I've trodden new ground in the path from database to renderer. I
>> encourage developers who are interested in the GroupSymbolizer to read
>> at least
>> https://github.com/kennykb/osm-shields/wiki/Using-the-GroupSymbolizer
>> - it has a number of tricks to structure the results in a way that the
>> GroupSymbolizer can consume and that renders well. The disadvantage to
>> using the GroupSymbolizer is that Phil!'s shield clusters were rather
>> more attractive visually, since they were aligned to lie in the
>> direction of a way. The advantage is that the current approach can run
>> on an unpatched Mapnik, as opposed to Phil!'s original, which requires
>> at least patching Mapnik to use a read/write connection to the
>> database.
>>
>> Managing, reliably, the association between ways and the routes in
>> which they participate requires a couple of database tables that a
>> stock osm2pgsql does not produce. I would very much appreciate any
>> commentary from developers of osm2pgsql and Mapnik, particularly,
>> about the issues discussed in
>>
>> https://github.com/kennykb/osm-shields/wiki/Maintaining-the-association-between-ways-and-routes
>> What I'm currently doing works well for my own use, which is driven by
>> daily updates to extracts at Geofabrik, but will obviously not scale
>> to a whole planet and minutely updates.
>>
>> Finally, I'd really like to invite anyone with the necessary SVG
>> skills to contribute shield graphics 

Re: [Talk-us] ref=* tags on links

[Paul Johnson]

On Fri, Aug 24, 2018, 14:33 Richard Welty  wrote:

> On 8/24/18 3:15 PM, Paul Johnson wrote:
> > This is a criticism I've had about the Standard renderer for a while
> > now.  Andy Allan's rendering refs from relations.  Osmand is rendering
> > refs from relations.  Magic Earth is rendering refs from relations.
> > Pretty sure Mapbox and Rand McNally are as well.
> "don't tag for the renderer" - but we lose sight of the fact that there are
> multiple renderers, and non-renderer data consumers on top of that.
>

And?

It's been obvious for about a decade now that this exact thing was going to
happen, let's make it happen already.

>
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] ref=* tags on links

[OSM Volunteer stevea]

On Aug 24, 2018, at 11:41 AM, Evin Fairchild  wrote:
> Hey, I totally agree that we need to fix the rendering so that the renderer 
> will show ref tags on route relations. But until then, it's impractical to 
> expect people to avoid putting the ref tags on the ways.

Evin, we agree to disagree about "practicality."  Defects can be so severe that 
workarounds cease as solutions.  If/as more data entry which tags for the 
renderer STOPS (no more bandages), and the real wound is seen for what it is (a 
problem that must be fixed), a much stronger incentive to fix exists.  We are 
not there now because of all the bandages, though we may get there if data 
entry more fully embraces "don't code for the renderer:"  shields don't get 
rendered properly, routing seems to (or does) fail, etc.  Either way (we can't 
have it both ways), the ONLY eventual solution is to fix what's broken.  Mihai 
broached the topic, again (thank you), here we are.

It seems "until then" is good enough for some people.  As I can only speak for 
myself, I say "not good enough for me."  Identifying defects is an absolutely 
critical process in any software endeavor, OSM included.  And, as this is a 
specific/localized problem, I wish to build stronger methodologies in OSM for 
our ability to identify/recognize ANY problem in our data-to-render pipelines, 
while being supported by our community in our quest to fix them.  My annoyance 
IS at the renderer itself.  "Push for it to get fixed" is exactly what this is.

As crucial "render stack coders" (right on, Martijn!), are clearly a critical 
OSM resource, they can't be expected to service every single problem, so we 
have what has evolved.  But, we must prioritize.  This is correct:  some 
defects are purely cosmetic, some are high-priority.  There is a rich spectrum 
of multi-dimensional methods to measure (and hence prioritize) software 
defects.  However, "pretending away" with "it's impractical" and "don't code 
for the renderer" must be identified as what they are:  dancing/hand-waving to 
buy some time until the demand (to fix defects) catches up with the 
supply/reality of them actually getting fixed.  OSM simply must get better at 
this.  I may not know exactly how today, but decades of improving exactly this 
process at major software companies tells me that's what this is and that's 
what we must do.  The process remains opaque quite likely deliberately to 
"obfuscate away" demands on critical resources.  Let's open that up, please; 
Open is our first name.

> I do agree with not tagging for the renderer, but I was merely pointing out 
> that it's impractical to expect EVERYONE to follow it in this case until the 
> renderer is fixed.

To make my point clearly:  calling it "impractical" prolongs the problem by 
winking and nodding at slapping bandages on a wound.  The "short-term bandage 
window" is or should be closed by now.  Paul Johnson is right:  dinosaurs like 
ten-year old bugs ought to be fixed.  If you want to say "it's impractical to 
expect..." you can.  I am saying "let's be practical by fixing what is broken." 
 That's what works.

Really, this is a much wider conversation, as you (Evin) identify about 
Washington state route shields and Kevin Kenny's recent "resurrection" of 
similar topics.  Yes, the data-to-render pipelines can be complex; I 
acknowledge that, this is a fundamental "tall mountain" of OSM.  But I continue 
to say "fix bugs, don't bandage them" (rather than wink or say "that's 
impractical").  Andy's awesome work to streamline mapnik into Carto is an 
excellent example of this tenet:  our project will either learn how to fix 
complexities in renderers (often by simplification of the codebase), or we will 
self-destruct in endless discussions like this.  I'd much rather take what is 
known to be a proven successful path.  So, let's improve our render-defect 
fixing pipeline, as it is rather broken.  No judgement there, rather 
identification of problems needing fixing.  We've done it before, we'll do it 
again, only better.

SteveA
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] ref=* tags on links

[Richard Welty]

On 8/24/18 3:15 PM, Paul Johnson wrote:
> This is a criticism I've had about the Standard renderer for a while
> now.  Andy Allan's rendering refs from relations.  Osmand is rendering
> refs from relations.  Magic Earth is rendering refs from relations. 
> Pretty sure Mapbox and Rand McNally are as well.
"don't tag for the renderer" - but we lose sight of the fact that there are
multiple renderers, and non-renderer data consumers on top of that.

richard

-- 
rwe...@averillpark.net
 Averill Park Networking - GIS & IT Consulting
 OpenStreetMap - PostgreSQL - Linux
 Java - Web Applications - Search


___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Talk-us Digest, Vol 129, Issue 27

[Paul Johnson]

Use procmail to split digests into their original individual messages
before replying, please.

On Fri, Aug 24, 2018, 12:57 OSM Volunteer stevea 
wrote:

> > it's impractical for people to do what you're suggesting.
>
> By "you" Evin means Paul Johnson and by "do what you're suggesting" —
> eliminating ref=* tags on ways — (as they are 100% redundant if the way is
> part of the appropriate route relations) Paul's suggestion is excellent.
> It is correct, not impractical.
>
> Continuing to put ref=* tags on ways is called a "workaround."  Like a
> bandage on a wound, workarounds can be decent short-term solutions, but the
> real healing which OSM must complete is for renderers to respect route
> relation tags.  All else is folly.
>

And a problem that no longer required a workaround as of October 2007 when
relations were introduced.  What kind of lead time do we need to phase out
a workaround?
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] ref=* tags on links

[Paul Johnson]

On Fri, Aug 24, 2018, 13:41 Evin Fairchild  wrote:

> Anyway, to get back on topic, I don't agree with tagging the ref tags on
> link roads, as long as it's part of the route relation. I have seen
> instances, though, where people tag what should be a motorway link as a
> motorway when a route exits off a freeway to get the route number to
> render, and I'm not exactly fond of that practice.
>

There are some arguable situations of motorways diverging without a link,
but yeah, currently at least the standard renderer doesn't bother with ref
on link to begin with right now (though I remember it did back before
carto).

>
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] ref=* tags on links

[Paul Johnson]

This is a criticism I've had about the Standard renderer for a while now.
Andy Allan's rendering refs from relations.  Osmand is rendering refs from
relations.  Magic Earth is rendering refs from relations.  Pretty sure
Mapbox and Rand McNally are as well.

On Fri, Aug 24, 2018, 12:03 Evin Fairchild  wrote:

> The only way you can get people to stop putting reg tags on ways and only
> put them on relations is if the renderer actually rendered reg tags from
> relations. Currently it doesn't do this, so it's impractical for people to
> do what you're suggesting. Yeah, yeah, yeah, I know, don't tag for the
> renderer, but I'd you don't have route numbers show up at all, them this
> really reduces the usability of the map. It's such an important thing that
> there's no way you can get people to stop putting the reg tags on ways
> unless the renderer rendered the ref tags for the whole relation.
>
> -Evin (compdude)
>
> On Fri, Aug 24, 2018, 9:56 AM Paul Johnson  wrote:
>
>> The ref=* tag on ways is already 100% redundant if the way is already a
>> part of the appropriate route relations and should be phased out so ref can
>> be used to actually describe the way's ref, where applicable.
>>
>> Also, can we kill this dinosaur entirely already?  Route relations have
>> been a widely accepted thing for a decade now, if you're not using route
>> relations for your primary source of route information (instead of
>> expecting tags on some other non route object to tell you), then you're
>> doing it wrong and you don't matter.
>>
>> On Fri, Aug 24, 2018, 07:38 Mihai Iepure 
>> wrote:
>>
>>> Hey everyone!
>>>
>>>
>>>
>>> We’re looking for your opinion on the existence of ref tags on links –
>>> should it be there? Is it redundant if the link is already in a route
>>> relation that has the ref tag?
>>>
>>>
>>>
>>> We’ve created a Github ticket
>>>  to
>>> let us know what you think, so feel free to post your thoughts there.
>>>
>>>
>>>
>>> Thanks in advance!
>>>
>>>
>>>
>>> Mihai Iepure
>>> Map Analyst
>>>
>>> [image: Description: cid:image002.png@01CCCAE5.664FA940]
>>>
>>> www.telenav.com
>>>
>>>
>>> ___
>>> Talk-us mailing list
>>> Talk-us@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/talk-us
>>>
>> ___
>> Talk-us mailing list
>> Talk-us@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-us
>>
>
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] ref=* tags on links

[Evin Fairchild]

Hey, I totally agree that we need to fix the rendering so that the renderer
will show ref tags on route relations. But until then, it's impractical to
expect people to avoid putting the ref tags on the ways. I do agree with
not tagging for the renderer, but I was merely pointing out that it's
impractical to expect EVERYONE to follow it in this case until the renderer
is fixed.

There's always gonna be people who will be like "I want to see the route
numbers so I'm just gonna circumvent tagging convention and tag the ref
tags on the ways instead of just the relation." As an example, I remember
back before Andy Allan created Carto, the code for the Mapnik stylesheet
was super complex and so there were a lot of bugs that took forever to get
fixed, including one where river names were not being displayed, so people
would tag rivers as streams to get the name to show up, even though that's
tagging for the renderer. I never fixed those things as I could totally
understand why people would do that and expecting people to follow the
"don't tag for the renderer" rule in that case is overly legalistic.
Instead of being annoyed that people tag for the renderer, turn your
annoyance at the renderer itself and push for it to get fixed or help fix
it if you have the expertise.

Hopefully we can get actual route shields implemented too. That's what got
me to create route relations for all of WA's state routes several years ago
when Phil Gold was working on making the shields. OSM would look awesome in
the US if we had those route shields!

Anyway, to get back on topic, I don't agree with tagging the ref tags on
link roads, as long as it's part of the route relation. I have seen
instances, though, where people tag what should be a motorway link as a
motorway when a route exits off a freeway to get the route number to
render, and I'm not exactly fond of that practice.

-Evin (compdude)

On Fri, Aug 24, 2018, 10:57 AM OSM Volunteer stevea <
stevea...@softworkers.com> wrote:

> > Evin Fairchild  wrote
> > The only way you can get people to stop putting reg tags on ways and
> only put them on relations is if the renderer actually rendered reg tags
> from relations. Currently it doesn't do this, so
>
> All good and correct so far...
>
> > it's impractical for people to do what you're suggesting.
>
> By "you" Evin means Paul Johnson and by "do what you're suggesting" —
> eliminating ref=* tags on ways — (as they are 100% redundant if the way is
> part of the appropriate route relations) Paul's suggestion is excellent.
> It is correct, not impractical.
>
> Continuing to put ref=* tags on ways is called a "workaround."  Like a
> bandage on a wound, workarounds can be decent short-term solutions, but the
> real healing which OSM must complete is for renderers to respect route
> relation tags.  All else is folly.
>
> > Yeah, yeah, yeah, I know, don't tag for the renderer,
>
> OSM's tenet of "don't tag for the renderer" is something I respect.  Yet
> (especially in this case) it has qualities of "magical thinking" whereby
> the wound is artificially babied along by pretending away that the real
> work renderers must (MUST!) do is to fully respect long-established data
> structures renderers purport to represent.  If that is hard work
> (evidently, it is), well, let's roll up our sleeves and code (FIX!) our
> renderers so they properly visually represent our data.
>
> Babying along wounds, pretending away and magical thinking are elements of
> sad, broken, amateurish projects:  they'll "get you through the night," and
> for too long in OSM, they have.  But as OSM matures into a happy, working,
> professional-grade project (we have, we do) that simply doesn't cut it any
> longer.  Someone has to say this — again and again, apparently — until the
> real solution of "this is hard work, but we must do it" is completed.
>
> > but I'd you don't have route numbers show up at all, them this really
> reduces the usability of the map.
>
> What a fantastic incentive to fix renderers:  evidence of "tag like we say
> we should tag" means "hm, renderers don't respect that!"  We can no longer
> say "don't code for the renderer," wink at those who do and continue to say
> and do this while "rendering incompletely."  It is disingenuous and shows
> that something is fundamentally broken in our project.  We MUST fix
> renderers or we DESERVE monikers of "sad, broken, amateurish."
>
> > It's such an important thing that there's no way you can get people to
> stop putting the reg tags on ways unless the renderer rendered the ref tags
> for the whole relation.
>
> It is circular logic (explained) and circular logic is broken.  We must
> fix our renderers so they fully respect our well-established data
> structures.  No longer can we be told "don't pay attention to that man
> behind the curtain" while winking and workarounds fight each other for
> dominance:  OSM loses (big time) in the long-run as we continue to fool
> ourselves with the folly of these 

Re: [Talk-us] Shaped highway shields - trying to revive

[Martijn van Exel]

Agreed. I think it's really nice to have active thinking and work around this. 
The key is to get the rendering stack people involved. Perhaps Paul Norman can 
function as a liaison?

Martijn

Sent from my iPhone

> On Aug 24, 2018, at 12:06, Evin Fairchild  wrote:
> 
> Really glad to see that someone is reviving this and actually taking the step 
> to get it rendered. Frankly, I never understood why Phil didn't do this in 
> the first place. I even mentioned this to him at the time (can't remember his 
> response though).
> 
> -Evin (compdude)
> 
>> On Wed, Aug 22, 2018, 2:21 PM Kevin Kenny  wrote:
>> (I apologize in advance to the tile-serving community if this message
>> is inappropriate. I see that traffic on that list is largely limited
>> to highly specific technical discussions, but couldn't see a more
>> appropriate forum.)
>> 
>> For several years now, I've been using the support code for shaped
>> shields in OSM, originally developed by Phil! Gold and Richard Weait,
>> to render North American-style maps. A typical example can be found at
>> https://kbk.is-a-geek.net/catskills/test4.html?la=41.4143=-74.4233=14
>> In that view, you can see distinct shields for Interstate, US, New
>> York, and county routes, and at least one concurrence (New York 17M
>> aligned with US 6). Incidentally, Phil's is the only renderer that
>> I've seen that can make sense of cases like West Virginia's bizarre
>> double route numbers, as seen in
>> https://kbk.is-a-geek.net/catskills/test4.html?la=41.4143=-74.4233=14
>> .
>> 
>> The visual distinction among highway shields is really necessary in
>> North America, where there are so many different route networks
>> overlaid.
>> 
>> In the course of working with the code, I've made a number of changes
>> and become seriously out of sync with the main development line, which
>> appears to be moribund. (Phil! and Richard have not answered recent
>> queries; I suspect that I have obsolete contact information, but the
>> messages also have not been returned undelivered.)
>> 
>> Accordingly, I've (quite reluctantly) created my own repository -
>> https://github.com/kennykb/osm-shields - with material from the
>> project. The shield templates to be found there are mostly those of
>> Phil! (I added only a handful), but the code to manage shields is
>> almost entirely new. Some significant changes are:
>> 
>> The list of shields to be rendered is obtained from the database
>> itself, rather than being predetermined by a configuration file for
>> each network. This has the disadvantage that refs that are known to be
>> problematic may be rendered (but in most cases they ought to be
>> unsigned_ref). On the other hand, it has the distinct advantage that
>> as mappers continue to create the route relations, the corresponding
>> shields appear virtually automatically.
>> 
>> The composition of shield clusters, rather than being handled by a
>> stored procedure in the database, is done using a GroupSymbolizer in
>> Mapnik. I suspect, given the dearth of discussion that I find in a
>> Google query, that I'm the first user to attempt to use
>> GroupSymbolizer with actual open-ended shield clusters, and therefore
>> that I've trodden new ground in the path from database to renderer. I
>> encourage developers who are interested in the GroupSymbolizer to read
>> at least 
>> https://github.com/kennykb/osm-shields/wiki/Using-the-GroupSymbolizer
>> - it has a number of tricks to structure the results in a way that the
>> GroupSymbolizer can consume and that renders well. The disadvantage to
>> using the GroupSymbolizer is that Phil!'s shield clusters were rather
>> more attractive visually, since they were aligned to lie in the
>> direction of a way. The advantage is that the current approach can run
>> on an unpatched Mapnik, as opposed to Phil!'s original, which requires
>> at least patching Mapnik to use a read/write connection to the
>> database.
>> 
>> Managing, reliably, the association between ways and the routes in
>> which they participate requires a couple of database tables that a
>> stock osm2pgsql does not produce. I would very much appreciate any
>> commentary from developers of osm2pgsql and Mapnik, particularly,
>> about the issues discussed in
>> https://github.com/kennykb/osm-shields/wiki/Maintaining-the-association-between-ways-and-routes
>> What I'm currently doing works well for my own use, which is driven by
>> daily updates to extracts at Geofabrik, but will obviously not scale
>> to a whole planet and minutely updates.
>> 
>> Finally, I'd really like to invite anyone with the necessary SVG
>> skills to contribute shield graphics for the missing networks. If
>> you're also a programmer and want to take a whack at the rest of the
>> procedure in https://github.com/kennykb/osm-shields/wiki/Adding-new-networks,
>> and give me a pull request or ask for help, that would be even better,
>> but even the artwork would be a time-saver.
>> 
>> If you've got this far in reading, 

Re: [Talk-us] ref=* tags on links

[Martijn van Exel]

Agree with that, Evin. Unfortunately I think there are still quite a few 
countries where route relations are not as widely used / accepted (I remember 
the UK bring among them? Perhaps someone can do an overpass query to visualize) 
so unless we get everyone on board with them we're likely stuck with 
redundancy. 

Martijn

Sent from my iPhone

> On Aug 24, 2018, at 12:02, Evin Fairchild  wrote:
> 
> The only way you can get people to stop putting reg tags on ways and only put 
> them on relations is if the renderer actually rendered reg tags from 
> relations. Currently it doesn't do this, so it's impractical for people to do 
> what you're suggesting. Yeah, yeah, yeah, I know, don't tag for the renderer, 
> but I'd you don't have route numbers show up at all, them this really reduces 
> the usability of the map. It's such an important thing that there's no way 
> you can get people to stop putting the reg tags on ways unless the renderer 
> rendered the ref tags for the whole relation.
> 
> -Evin (compdude)
> 
>> On Fri, Aug 24, 2018, 9:56 AM Paul Johnson  wrote:
>> The ref=* tag on ways is already 100% redundant if the way is already a part 
>> of the appropriate route relations and should be phased out so ref can be 
>> used to actually describe the way's ref, where applicable.
>> 
>> Also, can we kill this dinosaur entirely already?  Route relations have been 
>> a widely accepted thing for a decade now, if you're not using route 
>> relations for your primary source of route information (instead of expecting 
>> tags on some other non route object to tell you), then you're doing it wrong 
>> and you don't matter.
>> 
>>> On Fri, Aug 24, 2018, 07:38 Mihai Iepure  wrote:
>>> Hey everyone!
>>> 
>>>  
>>> 
>>> We’re looking for your opinion on the existence of ref tags on links – 
>>> should it be there? Is it redundant if the link is already in a route 
>>> relation that has the ref tag?
>>> 
>>>  
>>> 
>>> We’ve created a Github ticket to let us know what you think, so feel free 
>>> to post your thoughts there.
>>> 
>>>  
>>> 
>>> Thanks in advance!
>>> 
>>>  
>>> 
>>> Mihai Iepure
>>> Map Analyst
>>> 
>>> 
>>> 
>>> www.telenav.com
>>> 
>>>  
>>> 
>>> ___
>>> Talk-us mailing list
>>> Talk-us@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/talk-us
>> ___
>> Talk-us mailing list
>> Talk-us@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-us
> ___
> Talk-us mailing list
> Talk-us@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-us
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Talk-us Digest, Vol 129, Issue 27

[OSM Volunteer stevea]

> Evin Fairchild  wrote
> The only way you can get people to stop putting reg tags on ways and only put 
> them on relations is if the renderer actually rendered reg tags from 
> relations. Currently it doesn't do this, so

All good and correct so far...

> it's impractical for people to do what you're suggesting.

By "you" Evin means Paul Johnson and by "do what you're suggesting" — 
eliminating ref=* tags on ways — (as they are 100% redundant if the way is part 
of the appropriate route relations) Paul's suggestion is excellent.  It is 
correct, not impractical.

Continuing to put ref=* tags on ways is called a "workaround."  Like a bandage 
on a wound, workarounds can be decent short-term solutions, but the real 
healing which OSM must complete is for renderers to respect route relation 
tags.  All else is folly.

> Yeah, yeah, yeah, I know, don't tag for the renderer,

OSM's tenet of "don't tag for the renderer" is something I respect.  Yet 
(especially in this case) it has qualities of "magical thinking" whereby the 
wound is artificially babied along by pretending away that the real work 
renderers must (MUST!) do is to fully respect long-established data structures 
renderers purport to represent.  If that is hard work (evidently, it is), well, 
let's roll up our sleeves and code (FIX!) our renderers so they properly 
visually represent our data.

Babying along wounds, pretending away and magical thinking are elements of sad, 
broken, amateurish projects:  they'll "get you through the night," and for too 
long in OSM, they have.  But as OSM matures into a happy, working, 
professional-grade project (we have, we do) that simply doesn't cut it any 
longer.  Someone has to say this — again and again, apparently — until the real 
solution of "this is hard work, but we must do it" is completed.

> but I'd you don't have route numbers show up at all, them this really reduces 
> the usability of the map.

What a fantastic incentive to fix renderers:  evidence of "tag like we say we 
should tag" means "hm, renderers don't respect that!"  We can no longer say 
"don't code for the renderer," wink at those who do and continue to say and do 
this while "rendering incompletely."  It is disingenuous and shows that 
something is fundamentally broken in our project.  We MUST fix renderers or we 
DESERVE monikers of "sad, broken, amateurish."

> It's such an important thing that there's no way you can get people to stop 
> putting the reg tags on ways unless the renderer rendered the ref tags for 
> the whole relation.

It is circular logic (explained) and circular logic is broken.  We must fix our 
renderers so they fully respect our well-established data structures.  No 
longer can we be told "don't pay attention to that man behind the curtain" 
while winking and workarounds fight each other for dominance:  OSM loses (big 
time) in the long-run as we continue to fool ourselves with the folly of these 
contradictions.

The bottom line, "easy as cake, simple as pie:"  FIX WHAT IS BROKEN.  Is this 
difficult software development?  That's OK, let's do it.  No more excuses.  It 
isn't impossible to avoid contradictions, though it may be hard work.

With the greatest respect for our project,
SteveA
California
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Shaped highway shields - trying to revive

[Evin Fairchild]

Really glad to see that someone is reviving this and actually taking the
step to get it rendered. Frankly, I never understood why Phil didn't do
this in the first place. I even mentioned this to him at the time (can't
remember his response though).

-Evin (compdude)

On Wed, Aug 22, 2018, 2:21 PM Kevin Kenny  wrote:

> (I apologize in advance to the tile-serving community if this message
> is inappropriate. I see that traffic on that list is largely limited
> to highly specific technical discussions, but couldn't see a more
> appropriate forum.)
>
> For several years now, I've been using the support code for shaped
> shields in OSM, originally developed by Phil! Gold and Richard Weait,
> to render North American-style maps. A typical example can be found at
> https://kbk.is-a-geek.net/catskills/test4.html?la=41.4143=-74.4233=14
> In that view, you can see distinct shields for Interstate, US, New
> York, and county routes, and at least one concurrence (New York 17M
> aligned with US 6). Incidentally, Phil's is the only renderer that
> I've seen that can make sense of cases like West Virginia's bizarre
> double route numbers, as seen in
> https://kbk.is-a-geek.net/catskills/test4.html?la=41.4143=-74.4233=14
> .
>
> The visual distinction among highway shields is really necessary in
> North America, where there are so many different route networks
> overlaid.
>
> In the course of working with the code, I've made a number of changes
> and become seriously out of sync with the main development line, which
> appears to be moribund. (Phil! and Richard have not answered recent
> queries; I suspect that I have obsolete contact information, but the
> messages also have not been returned undelivered.)
>
> Accordingly, I've (quite reluctantly) created my own repository -
> https://github.com/kennykb/osm-shields - with material from the
> project. The shield templates to be found there are mostly those of
> Phil! (I added only a handful), but the code to manage shields is
> almost entirely new. Some significant changes are:
>
> The list of shields to be rendered is obtained from the database
> itself, rather than being predetermined by a configuration file for
> each network. This has the disadvantage that refs that are known to be
> problematic may be rendered (but in most cases they ought to be
> unsigned_ref). On the other hand, it has the distinct advantage that
> as mappers continue to create the route relations, the corresponding
> shields appear virtually automatically.
>
> The composition of shield clusters, rather than being handled by a
> stored procedure in the database, is done using a GroupSymbolizer in
> Mapnik. I suspect, given the dearth of discussion that I find in a
> Google query, that I'm the first user to attempt to use
> GroupSymbolizer with actual open-ended shield clusters, and therefore
> that I've trodden new ground in the path from database to renderer. I
> encourage developers who are interested in the GroupSymbolizer to read
> at least
> https://github.com/kennykb/osm-shields/wiki/Using-the-GroupSymbolizer
> - it has a number of tricks to structure the results in a way that the
> GroupSymbolizer can consume and that renders well. The disadvantage to
> using the GroupSymbolizer is that Phil!'s shield clusters were rather
> more attractive visually, since they were aligned to lie in the
> direction of a way. The advantage is that the current approach can run
> on an unpatched Mapnik, as opposed to Phil!'s original, which requires
> at least patching Mapnik to use a read/write connection to the
> database.
>
> Managing, reliably, the association between ways and the routes in
> which they participate requires a couple of database tables that a
> stock osm2pgsql does not produce. I would very much appreciate any
> commentary from developers of osm2pgsql and Mapnik, particularly,
> about the issues discussed in
>
> https://github.com/kennykb/osm-shields/wiki/Maintaining-the-association-between-ways-and-routes
> What I'm currently doing works well for my own use, which is driven by
> daily updates to extracts at Geofabrik, but will obviously not scale
> to a whole planet and minutely updates.
>
> Finally, I'd really like to invite anyone with the necessary SVG
> skills to contribute shield graphics for the missing networks. If
> you're also a programmer and want to take a whack at the rest of the
> procedure in
> https://github.com/kennykb/osm-shields/wiki/Adding-new-networks,
> and give me a pull request or ask for help, that would be even better,
> but even the artwork would be a time-saver.
>
> If you've got this far in reading, thanks! I know this was a long
> message, and I hope that I've not wasted too much of anyone's time.
>
> ___
> Talk-us mailing list
> Talk-us@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-us
>
___
Talk-us mailing list
Talk-us@openstreetmap.org

Re: [Talk-us] ref=* tags on links

[Evin Fairchild]

The only way you can get people to stop putting reg tags on ways and only
put them on relations is if the renderer actually rendered reg tags from
relations. Currently it doesn't do this, so it's impractical for people to
do what you're suggesting. Yeah, yeah, yeah, I know, don't tag for the
renderer, but I'd you don't have route numbers show up at all, them this
really reduces the usability of the map. It's such an important thing that
there's no way you can get people to stop putting the reg tags on ways
unless the renderer rendered the ref tags for the whole relation.

-Evin (compdude)

On Fri, Aug 24, 2018, 9:56 AM Paul Johnson  wrote:

> The ref=* tag on ways is already 100% redundant if the way is already a
> part of the appropriate route relations and should be phased out so ref can
> be used to actually describe the way's ref, where applicable.
>
> Also, can we kill this dinosaur entirely already?  Route relations have
> been a widely accepted thing for a decade now, if you're not using route
> relations for your primary source of route information (instead of
> expecting tags on some other non route object to tell you), then you're
> doing it wrong and you don't matter.
>
> On Fri, Aug 24, 2018, 07:38 Mihai Iepure  wrote:
>
>> Hey everyone!
>>
>>
>>
>> We’re looking for your opinion on the existence of ref tags on links –
>> should it be there? Is it redundant if the link is already in a route
>> relation that has the ref tag?
>>
>>
>>
>> We’ve created a Github ticket
>>  to let
>> us know what you think, so feel free to post your thoughts there.
>>
>>
>>
>> Thanks in advance!
>>
>>
>>
>> Mihai Iepure
>> Map Analyst
>>
>> [image: Description: cid:image002.png@01CCCAE5.664FA940]
>>
>> www.telenav.com
>>
>>
>> ___
>> Talk-us mailing list
>> Talk-us@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-us
>>
> ___
> Talk-us mailing list
> Talk-us@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-us
>
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] ref=* tags on links

[Paul Johnson]

The ref=* tag on ways is already 100% redundant if the way is already a
part of the appropriate route relations and should be phased out so ref can
be used to actually describe the way's ref, where applicable.

Also, can we kill this dinosaur entirely already?  Route relations have
been a widely accepted thing for a decade now, if you're not using route
relations for your primary source of route information (instead of
expecting tags on some other non route object to tell you), then you're
doing it wrong and you don't matter.

On Fri, Aug 24, 2018, 07:38 Mihai Iepure  wrote:

> Hey everyone!
>
>
>
> We’re looking for your opinion on the existence of ref tags on links –
> should it be there? Is it redundant if the link is already in a route
> relation that has the ref tag?
>
>
>
> We’ve created a Github ticket
>  to let
> us know what you think, so feel free to post your thoughts there.
>
>
>
> Thanks in advance!
>
>
>
> Mihai Iepure
> Map Analyst
>
> [image: Description: cid:image002.png@01CCCAE5.664FA940]
>
> www.telenav.com
>
>
> ___
> Talk-us mailing list
> Talk-us@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-us
>
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

[Talk-us] ref=* tags on links

[Mihai Iepure]

Hey everyone!

We're looking for your opinion on the existence of ref tags on links - should 
it be there? Is it redundant if the link is already in a route relation that 
has the ref tag?

We've created a Github 
ticket to let 
us know what you think, so feel free to post your thoughts there.

Thanks in advance!

Mihai Iepure
Map Analyst
[Description: cid:image002.png@01CCCAE5.664FA940]
www.telenav.com

___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us