ref=* tags on links

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

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
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-us
Reply | Threaded
Open this post in threaded view
|

Re: ref=* tags on links

Paul Johnson-3
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 <[hidden email]> 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
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-us

_______________________________________________
Talk-us mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-us

image001.png (2K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: 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 <[hidden email]> 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 <[hidden email]> 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

Description: cid:image002.png@01CCCAE5.664FA940

www.telenav.com

 

_______________________________________________
Talk-us mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-us
_______________________________________________
Talk-us mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-us

_______________________________________________
Talk-us mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-us
Reply | Threaded
Open this post in threaded view
|

Re: ref=* tags on links

Martijn van Exel-3
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-us
_______________________________________________
Talk-us mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-us
_______________________________________________
Talk-us mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-us

_______________________________________________
Talk-us mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-us
Reply | Threaded
Open this post in threaded view
|

Re: ref=* tags on links

Evin Fairchild
In reply to this post by Mihai Iepure
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 <[hidden email]> wrote:
> Evin Fairchild <[hidden email]> 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
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-us
Reply | Threaded
Open this post in threaded view
|

Re: ref=* tags on links

Paul Johnson-3
In reply to this post by Evin Fairchild
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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

Description: cid:image002.png@01CCCAE5.664FA940

www.telenav.com

 

_______________________________________________
Talk-us mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-us
_______________________________________________
Talk-us mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-us

_______________________________________________
Talk-us mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-us
Reply | Threaded
Open this post in threaded view
|

Re: ref=* tags on links

Paul Johnson-3
In reply to this post by Evin Fairchild


On Fri, Aug 24, 2018, 13:41 Evin Fairchild <[hidden email]> 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
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-us
Reply | Threaded
Open this post in threaded view
|

Re: ref=* tags on links

Richard Welty-2
In reply to this post by Paul Johnson-3
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

--
[hidden email]
 Averill Park Networking - GIS & IT Consulting
 OpenStreetMap - PostgreSQL - Linux
 Java - Web Applications - Search


_______________________________________________
Talk-us mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-us
Reply | Threaded
Open this post in threaded view
|

Re: ref=* tags on links

stevea
In reply to this post by Evin Fairchild
On Aug 24, 2018, at 11:41 AM, Evin Fairchild <[hidden email]> 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
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-us
Reply | Threaded
Open this post in threaded view
|

Re: ref=* tags on links

Paul Johnson-3
In reply to this post by Richard Welty-2


On Fri, Aug 24, 2018, 14:33 Richard Welty <[hidden email]> 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
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-us
Reply | Threaded
Open this post in threaded view
|

Re: ref=* tags on links

Kevin Kenny-3
On Fri, Aug 24, 2018, 3:46 PM Paul Johnson <[hidden email]> wrote:


On Fri, Aug 24, 2018, 14:33 Richard Welty <[hidden email]> 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
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-us