Opened 10 years ago

Closed 5 years ago

#2599 closed enhancement (duplicate)

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

Reported by: Mark Pulley Owned by: mapnik-team@…
Priority: major Milestone:
Component: mapnik Version:
Keywords: mapnik relation Cc: jburgess777@…, JoshD

Description

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).

Change History (19)

comment:1 Changed 10 years ago by Richard

Relations are _not_ superways. The way should be tagged.

comment:2 in reply to:  1 ; Changed 10 years ago by John

Replying to 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.

comment:3 in reply to:  2 ; Changed 10 years ago by Richard

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.

comment:4 in reply to:  3 ; Changed 10 years ago by John

Replying to 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.

comment:5 in reply to:  4 ; Changed 10 years ago by Richard

Replying to 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.

comment:6 in reply to:  5 Changed 10 years ago by John

Replying to 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.

comment:7 Changed 10 years ago by 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.

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.

comment:8 in reply to:  7 ; Changed 10 years ago by John

Replying to 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.

comment:9 in reply to:  8 ; Changed 10 years ago by Ldp

Replying to 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.

comment:10 in reply to:  9 ; Changed 10 years ago by John

Replying to 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.

comment:11 in reply to:  10 Changed 10 years ago by Ldp

Cc: jburgess777@… added

Replying to 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.

comment:12 in reply to:  5 ; Changed 10 years ago by Mark Pulley

Replying to 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.

comment:13 Changed 8 years ago by JoshD

Cc: JoshD added

comment:14 in reply to:  12 ; Changed 8 years ago by Ldp

Replying to 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?

comment:15 in reply to:  14 Changed 8 years ago by Ldp

Replying to 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

comment:16 in reply to:  14 ; Changed 8 years ago by Mark Pulley

Replying to 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).

comment:17 in reply to:  16 Changed 8 years ago by Ldp

Replying to 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.

comment:18 Changed 5 years ago by math1985

Summary: Route numbers and names in relations not showing on Mapnik[roads] Route numbers and names in relations not showing on Mapnik

comment:19 Changed 5 years ago by math1985

Resolution: duplicate
Status: newclosed

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

Note: See TracTickets for help on using tickets.