Skip to content
This repository has been archived by the owner on Jul 24, 2021. It is now read-only.

[roads] Route numbers and names in relations not showing on Mapnik #2599

Closed
openstreetmap-trac opened this issue Jul 23, 2021 · 17 comments
Closed

Comments

@openstreetmap-trac
Copy link

Reporter: mrpulley
[Submitted to the original trac issue database at 4.31pm, Sunday, 3rd January 2010]

I've noticed that the route numbers and route names
aren't showing in Mapnik when relations are used. This happens if other tags e.g. "highway=" are left on the way and not transferred to the relation.

Example 1:
http://www.openstreetmap.org/browse/way/22964567 and http://www.openstreetmap.org/browse/relation/373955

The name and route number do not show up. Name and route number are in the relation, highway=secondary is on the way.

Example 2:
http://www.openstreetmap.org/browse/way/22737466 and http://www.openstreetmap.org/browse/relation/374114

Name and route numbers both show. All details including highway=secondary are in the relation.

I haven't tested what happens if "name=" is on the way (e.g. a highway uses a named street through a city).

@openstreetmap-trac
Copy link
Author

Author: Richard
[Added to the original trac issue at 3.32pm, Monday, 4th January 2010]

Relations are not superways. The way should be tagged.

@openstreetmap-trac
Copy link
Author

Author: JohnSmith
[Added to the original trac issue at 7.06pm, Monday, 4th January 2010]

Replying to [comment:1 Richard]:

Relations are not superways. The way should be tagged.

No but relations do group ways. Highways and the like often have shared segments and trying to tag a way with a local name, plus highway name becomes increasingly less efficient to parse.

Bogus but possible example:

name=Barney Street;Fred Highway; Wilma Highway
ref=A101;B201

Or we can simply use relations to describe the highway information separate from the local information.

@openstreetmap-trac
Copy link
Author

Author: Richard
[Added to the original trac issue at 10.36am, Tuesday, 5th January 2010]

I know what you're saying. The principle in OSM is that you split ways with the greatest level of 'granularity' - the canonical example being that a bridge is an entire way. So you should very rarely need the semi-colons.

Relations are indeed a good method of grouping these granular ways. But they shouldn't be overused, and they are an aid, not a replacement.

You can, for example, find the route of the A44 road in the UK by extracting all ways with ref=A44 within a given bounding box. Now admittedly XAPI, the tool of choice for this, does have performance issues atm but that's a technical issue not a data model problem.

There are people who'd additionally add a relation with "route=highway, ref=A44", and though I think this is unnecessary, I can see the appeal to some people. But that certainly doesn't remove the need to tag the ways with highway=trunk, ref=A44.

@openstreetmap-trac
Copy link
Author

Author: JohnSmith
[Added to the original trac issue at 11.55am, Tuesday, 5th January 2010]

Replying to [comment:3 Richard]:

You can, for example, find the route of the A44 road in the UK by extracting all ways with ref=A44 within a given bounding box. Now admittedly XAPI, the tool of choice for this, does have

Unfortunately not everyone lives in the UK where everything is so clear cut and simple.

In Australia highways in places are nothing more than a dirt track and lots of them wind through small towns where they are mixed with local streets, this doesn't happen with motorways but again our road network differs greatly.

Have a look at the Bruce Highway for example, it goes from Brisbane to Cairns, possibly further I can't remember, and is one of the few highways designated a national highway. Which basically means some or all federal funding, rather than just state funding.

There is too many local names to mention.

Second problem, the Bruce Highway goes from being the M1 in Brisbane, to being the A1 north of Cooroy, the A1 is also used for other highways north of Cairns.

So the use of a relation here grouping common ways greatly helps things.

There are people who'd additionally add a relation with "route=highway, ref=A44", and though I think this is unnecessary, I can see the appeal to some people. But that certainly doesn't remove the need to tag the ways with highway=trunk, ref=A44.

We aren't tagging relations with highway=* tags, we are grouping local and inter-local roads as relations however.

@openstreetmap-trac
Copy link
Author

Author: Richard
[Added to the original trac issue at 3.58pm, Tuesday, 5th January 2010]

Replying to [comment:4 JohnSmith]:

Second problem, the Bruce Highway goes from being the M1 in Brisbane, to being the A1 north of Cooroy, the A1 is also used for other highways north of Cairns.

So the use of a relation here grouping common ways greatly helps things.

Oh, sure, I can see that. I think some of the US mappers pointed out the same thing. ISTR this was the main reason route relations were popularised anyway - the UK National Cycle Network often has two or three routes following the same road, and you couldn't get them both into one ncn_ref tag.

But where I think the OP has got it wrong is by using relations as a replacement for way tags, rather than an addition. Your suggested use is sensible if way tags aren't good enough. But there is no precedent for removing the tags entirely from the ways and putting them solely on the relations.

@openstreetmap-trac
Copy link
Author

Author: JohnSmith
[Added to the original trac issue at 7.05pm, Tuesday, 5th January 2010]

Replying to [comment:5 Richard]:

Oh, sure, I can see that. I think some of the US mappers pointed out the same thing. ISTR this
was the main reason route relations were popularised anyway - the UK National Cycle Network often has two or three routes following the same road, and you couldn't get them both into one ncn_ref tag.

Actually we mostly copied what they did in the US, probably for the same/similar reasons.

But where I think the OP has got it wrong is by using relations as a replacement for way tags, rather than an addition. Your suggested use is sensible if way tags aren't good enough. But there is no precedent for removing the tags entirely from the ways and putting them solely on the relations.

I'm not sure how to respond to this, because I'm pretty sure I've outlined a good case where ways are complicated either by sharing segments which causes an over abundance of information to be crammed into a set of tags.

IMHO it makes more sense to put the more important information into a relation and keep the more localised information on the ways, obviously for minor roads there is no need to remove the information from the ways just for the sake of consistency with more major roads.

@openstreetmap-trac
Copy link
Author

Author: Ldp
[Added to the original trac issue at 7.17pm, Tuesday, 5th January 2010]

@johnsmith: May I suggest you take this to the tagging mailing list first? There have been a few proposals already for these kinds of features, and it would be good to finally settle on one, describe exactly how it works, so we can then add the correct workings to osm2pgsql/mapnik.

You're currently relying on the way osm2pgsql handles relations where member ways are tagged vs. untagged, and that is never a good way to continue using. It might suddenly change, and then your tagging would be all wrong with respect to what renders.

@openstreetmap-trac
Copy link
Author

Author: JohnSmith
[Added to the original trac issue at 7.32pm, Tuesday, 5th January 2010]

Replying to [comment:7 Ldp]:

JohnSmith: May I suggest you take this to the tagging mailing list first? There have been a few proposals already for these kinds of features, and it would be good to finally settle on one, describe exactly how it works, so we can then add the correct workings to osm2pgsql/mapnik.

I'll be happy to, however I disagree with your next point.

You're currently relying on the way osm2pgsql handles relations where member ways are tagged vs. untagged, and that is never a good way to continue using. It might suddenly change, and then your tagging would be all wrong with respect to what renders.

Just because osm2pgsql does what it does isn't why we're tagging this way, when highways share segments, especially like in some places, it becomes an utter mess of tags, using relations splits the mess off into cleaner relations.

@openstreetmap-trac
Copy link
Author

Author: Ldp
[Added to the original trac issue at 7.41pm, Tuesday, 5th January 2010]

Replying to [comment:8 JohnSmith]:

Just because osm2pgsql does what it does isn't why we're tagging this way, when highways share segments, especially like in some places, it becomes an utter mess of tags, using relations splits the mess off into cleaner relations.

I agree that some way to collect common tags into relations is an approach to this. The name/ref tags on a heavily segmentized road are a prime example.

Still, it would be good to formalise this tagging scheme in such a way that it's well documented and well understandable by mappers. This would bring with it some measure of guarantee that osm2pgsql will not suddenly and unknowingly change its handling of these tagging situations. It will also mean the reason you opened this ticket, which is the difference in handling untagged vs tagged member ways, gets resolved in a clean and predictable way.

And lastly, we can then think about whether multiple identical tags for a segment of road should be handled in a special way when rendering.

@openstreetmap-trac
Copy link
Author

Author: JohnSmith
[Added to the original trac issue at 8.19pm, Tuesday, 5th January 2010]

Replying to [comment:9 Ldp]:

Still, it would be good to formalise this tagging scheme in such a way that it's well documented and well understandable by mappers. This would bring with it some measure of guarantee that osm2pgsql will not suddenly and unknowingly change its handling of these tagging situations. It will also mean the reason you opened this ticket, which is the difference in handling untagged vs tagged member ways, gets resolved in a clean and predictable way.

Well we have documented our usage of it, although it's mixed in with a lot of other aussie info and could possibly do well to stand on it's own.

It also differs from what is happening in the US because we think administrative polygons should be used for custom highway shields, instead of trying to tell the rendering software explicitly which shield to use. This leads on to another issue of pre-processing data to figure out the right highway shield to use, but that is still a work in progress.

@openstreetmap-trac
Copy link
Author

Author: Ldp
[Added to the original trac issue at 8.38pm, Tuesday, 5th January 2010]

Replying to [comment:10 JohnSmith]:

It also differs from what is happening in the US because we think administrative polygons should be used for custom highway shields, instead of trying to tell the rendering software explicitly which shield to use. This leads on to another issue of pre-processing data to figure out the right highway shield to use, but that is still a work in progress.

And a different issue/ticket altogether. Let's not detract from the issue at hand, and stick to your original request, and my counter request for good documentation and accepted global usage.

Adding in Jon, as maintainer of osm2pgsql.

@openstreetmap-trac
Copy link
Author

Author: mrpulley
[Added to the original trac issue at 3.16am, Thursday, 7th January 2010]

Replying to [comment:5 Richard]:

But where I think the OP has got it wrong is by using relations as a replacement for way tags, rather than an addition. Your suggested use is sensible if way tags aren't good enough. But there is no precedent for removing the tags entirely from the ways and putting them solely on the relations.

I wasn't planning to move all tags (e.g. highway=*) to the relation, I included it above as an example to show the problem of the route numbers and highway names in relations not showing up on Mapnik.

An example may help with points made by others.

http://www.openstreetmap.org/browse/way/30618562 - this is just a block away from where I work. It has a street name "Durham Street", but also a highway name and route number, separated into two relations:
http://www.openstreetmap.org/browse/relation/254498 - Great Western Highway, extends from Sydney to Bathurst.
http://www.openstreetmap.org/browse/relation/207581 - National Road 32, includes most of Great Western Highway, extends further west on part (not all) of Mitchell Highway, then continues further west on the Barrier Highway.
Relations help group the information on the highway name without crowding out individual street names in towns, but as per my original post these don't show up on Mapnik.

@openstreetmap-trac
Copy link
Author

Author: Ldp
[Added to the original trac issue at 2.05am, Sunday, 22nd May 2011]

Replying to [comment:12 mrpulley]:

I wasn't planning to move all tags (e.g. highway=*) to the relation, I included it above as an example to show the problem of the route numbers and highway names in relations not showing up on Mapnik.

The deciding factor in showing a shield, or more specifically: which shield, is based on the highway=* key. As you must be aware, we have different shield colours for the various different highway types. The road relations that are not tagged with highway=* do not carry enough information for the stylesheet to decide which shield to show.

As shown above, relations that do carry both highway=* and ref=* are being rendered with shields.

Relations help group the information on the highway name without crowding out individual street names in towns, but as per my original post these don't show up on Mapnik.

Not sure what you mean by "shield crowding out individual street names". Are you suggesting you're basing your tagging decisions on one renderer's handling of this situation? We have a dogma for that, you know?

@openstreetmap-trac
Copy link
Author

Author: Ldp
[Added to the original trac issue at 2.07am, Sunday, 22nd May 2011]

Replying to [comment:14 Ldp]:

Not sure what you mean by "shield crowding out individual street names". Are you suggesting you're basing your tagging decisions on one renderer's handling of this situation? We have a dogma for that, you know?

-shield in my previous quote

@openstreetmap-trac
Copy link
Author

Author: mrpulley
[Added to the original trac issue at 10.35am, Friday, 27th May 2011]

Replying to [comment:14 Ldp]:

The deciding factor in showing a shield, or more specifically: which shield, is based on the highway=* key. As you must be aware, we have different shield colours for the various different highway types. The road relations that are not tagged with highway=* do not carry enough information for the stylesheet to decide which shield to show.

Even if the way has the highway tag? Does that mean the highway=* tag should be added to the relation as well as the main way? Can the stylesheet not check the way?

Not sure what you mean by "shield crowding out individual street names". Are you suggesting you're basing your tagging decisions on one renderer's handling of this situation? We have a dogma for that, you know?

It's been 17 months since my last comment, so I had to read through it again to remind myself about the topic. I think I was referring to the highway name, not the shield (i.e. "Great Western Highway; Stewart Street" is rather long, "Stewart Street" on the street name with "Great Western Highway" on the relation is shorter).

@openstreetmap-trac
Copy link
Author

Author: Ldp
[Added to the original trac issue at 10.51am, Friday, 27th May 2011]

Replying to [comment:16 mrpulley]:

Even if the way has the highway tag? Does that mean the highway=* tag should be added to the relation as well as the main way? Can the stylesheet not check the way?

To mapnik, the way and the relation are two entirely unrelated line objects in the database. It (the renderer) cannot relate them in any way.

Even if it could, when a route relation encompasses several different classes of highway=*, which class should it use for deciding the shield? Given the current generic shields, that's something to be mindful about.

It's been 17 months since my last comment, so I had to read through it again to remind myself about the topic. I think I was referring to the highway name, not the shield (i.e. "Great Western Highway; Stewart Street" is rather long, "Stewart Street" on the street name with "Great Western Highway" on the relation is shorter).

If you tag both the way and the relation with a name=*, and a different one at that, it renders them both (separately), does it not? Whenever there is space for a label, of course.

@openstreetmap-trac
Copy link
Author

Author: math1985
[Added to the original trac issue at 10.11pm, Monday, 2nd June 2014]

This is being discussed on Github now: gravitystorm/openstreetmap-carto#596. Therefore, I will close the issue here.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

1 participant