gravitystorm
Render ref from route relationship
The following issue has been moved over from trac. It needs more discussion as it is not clear how this should be implemented.
Highway shields are only rendered when the ways themselves have a ref tag. Now, the different ways that form a road route are assembled into relations. For the sake of avoiding duplicate data the ref tags should be removed from the individual ways and applied to the relation only.
However, currently we only use ref tags on roads for rendering, and we ignore the ref tag on the relation.
Any idea how we could implement this?
Actually it is not entirely clear to me what is the recommended tagging. Perhaps tagging ref's on routes is incorrect tagging?
See also https://trac.openstreetmap.org/ticket/2599.
The same holds for name's on relations.
See also https://trac.openstreetmap.org/ticket/2599,
Am 03/giu/2014 um 00:09 schrieb math1985 [email protected]:
Actually it is not entirely clear to me what is the recommended tagging. Perhaps tagging ref's on routes is incorrect tagging?
no, recommended are refs on routes, and eventually on road ways as well, but the latter just for mapnik ;-)
I'd like to put in a vote to have this implemented ASAP.
OSM recommended tagging for a road route with a ref= is to use relations, e.g. http://www.openstreetmap.org/way/21548058 and NOT to put this information on individual ways.
Since Mapnik does not render road route relations at all, map editors don't consider a route 'done' until all the information is duplicated on individual ways, meaning it all has to be cleaned up later - and the longer this is unimplemented (and the more editors we get, especially say, in the US where OSM is growing), the worse this gets.
This is a case of users modifying OSM's database to work around a missing feature in a tool (here, support of road route relations).
A quick and dirty way of implementing this, presuming that relations can be read to render, would be to recursively get all road route relations on a way if the way is tagged with highway={motorway,trunk,primary,secondary,tertiary,unclassified, or residential}. De-dup any identical ref names and drop them - those could come from duplication on the way/relation/super-relations. Then, render them one per line.
So, for example...this example render would be three lines. US 41 (appears in 'ref' on way, on road route relation, and super relation, de-duped) CTH H (appears in 'ref' only on the way) WI 77 (appears in 'ref' only on road route relation)
I realize this introduces the additional problem of 'making the render look pretty', but as it is, people are doing concurrency in other 'wrong' ways, like 'WI 71;WI 99' or 'WI 71/99' which usually don't fit in the shield anyway. We'd be trading one poor render for another, but encouraging the correct OSM editing behavior.
OSM recommended tagging for a road route with a ref= is to use relations, e.g. http://www.openstreetmap.org/way/21548058 and NOT to put this information on individual ways.
No, recommended is to have both, which isn't ideal, but that's what's recommended.
No, recommended is to have both, which isn't ideal, but that's what's recommended.
I suspect that if this were implemented in openstreetmap-carto, the OSM recommendation would be changed to reflect that. That is, to prefer route relations over tagging ways when a route spans "significantly more than one" way.
I believe tagging both ways and relations is done because the most common renderers, (but most especially openstreetmap-carto) doesn't render the refs that appear on the route relations at all. If it did, the OSM project could revisit that best practice. Until 'ref' on relations is supported in rendering, telling the userbase 'Please put refs on route relations only' would appear to them to be "removing data from the rendered map" at http://www.openstreetmap.org/ .
Copied my comment from https://github.com/gravitystorm/openstreetmap-carto/issues/508#issuecomment-47234853 as per @skylerbunny's request:
FWIW, we spent a ton of time augmenting route relations (Interstates and US Highways mainly) in the U.S. with appropriate network and ref tags, so that we wouldn't have to rely on the brittle ref-on-ways tagging convention for determining the road designation. This is by no means finished - many state level networks remain to be done - but we have some tools in place in the U.S. to help guide this work, like the relation pages http://184.73.220.107/relationpages/
I would be hugely in favor of shield tagging based on route network / ref being rendered on osm.org - this would encourage what I consider proper tagging of network information and stop folks from duplicating this information on the ways, which is brittle and hard to maintain.
Insight from the Telenav perspective as a large scale user of OSM data: we ingest both refs on ways and network / ref on route relations to determine road network designations, but we'd much rather just use the relations for getting that data, and we're seeing lots of inconsistencies in the ref information on the ways, both between way and parent relation info and within the ways.
Given the current scarcity of route relations, we'll need to continue rendering ref tags.
(Highlighting of type=route route=road relations)
What I'm wondering is, how, while avoiding duplication.
The rendering tables don't have relation membership information, so I think we have to use postgis. Thoughts?
Well, the deeper technical implementation aside, assuming the existence of a tag can be compared between a way and a relation, I'd suggest this:
- If a ref exists on a way and also on a route relation, the route relation's ref wins and is rendered, and the one on the way is ignored. (If multiple route relations exist on the way, then concurrency applies. For 596, this may mean 'don't render anything', but we have the case of dealing with route concurrency open in issue #508.)
For long term maintainability of routes, we need to actively discourage 'ref on ways'. Doing this supports it merely for backwards compatibility but puts thrust behind using relations.
assuming the existence of a tag can be compared between a way and a relation
This is a fairly big assumption without membership information.
If a ref exists on a way and also on a route relation, the route relation's ref wins and is rendered, and the one on the way is ignored.
This would fail in the region I showed. It would also fail on the other side of the tunnel. The only route relations for roads I saw were for the E road network.
we have the case of dealing with route concurrency open in issue #508.)
#508 is about pictorial signs, not concurrency
On Thu, Jun 26, 2014 at 6:08 PM, Paul Norman [email protected] wrote:
assuming the existence of a tag can be compared between a way and a relation
This is a fairly big assumption without membership information.
If a ref exists on a way and also on a route relation, the route relation's ref wins and is rendered, and the one on the way is ignored.
This would fail in the region I showed. It would also fail on the other side of the tunnel. The only route relations for roads I saw were for the E road network.
This is however how we chose to do it for Scout. Take the relation network and ref tags, and fall back on ways where needed. Granted we have the 'luxury' of being US only. But you have to start somewhere, and if we're ever going to get to a state where folks tag road networks in a scalable, maintainable way, setting the right example in the main stylesheet is one of the better ways to do it. I know - tagging for the renderer is not supposed to be a guideline, but in a way that is what folks have been doing so far.
Martijn van Exel http://oegeo.wordpress.com/ http://openstreetmap.us/
Could use some European feedback, as I didn't see any route relations for country motorway systems in the area I looked, just cross-Europe networks. Is that the general way it's tagged, or are there variations by country within Europe?
It seems like many European mappers have been hesitant to have route refs duplicated on relations and their member ways. To be sure, route relations are being used, but the network and ref tags are much less common than in the U.S.
I think that’s because most countries in Europe distinguish route networks by alphabetic prefixes. There are secondary differences in signage; however, if an “M” is enough to get the point across, I would totally understand if a road map omits the symbol in 
to save space.
Meanwhile, in the U.S, we’ve tried for years to shoehorn route network names into the eight character allotment, but it’s hopeless when there’s a concurrency. To give but one example, Interstate 71 and Interstate 75 (highways of roughly equal importance to the region) share a major stretch of road in Kentucky. Alas, ref=I 71;I 75 is nine characters, so the shield won’t show no matter how far you zoom in. And that’s the best case: the rest of the abbreviations are two characters long.
Highway refs are tagged on ways in Great Britain. No way can have more than one ref (apart from the unsigned and generally unused E routes) - i.e. no "multiplexing" or "concurrency" - and each signposted ref is, in theory, unique within GB. Route relations would therefore be needless duplication, and significant extra work for the mapper.
If openstreetmap-carto gets support for road route relations for the US guys then that's great, but there is no intention (and nor should there be) to stop tagging refs on ways in GB and similar countries.
I would totally understand if a road map omits the symbol
I think you're mixing up issues - this issue is about using relations instead of ref on ways, not symbols.
eight character allotment
There's no reason we can't handle wider refs that I see.
In Germany, there are routes for motorways and some primaries ("Bundesstraßen"). I haven't seen many relations for secondary and tertiary highways ("Kreis-"/"Landesstraßen"). Note that some road relations are only parent relations for the TMC-Relations (Example: http://www.openstreetmap.org/relation/2166961).
Usually there's only one ref per road, except of some rare cases on motorways (Example on the A 8/A 81 here: http://www.openstreetmap.org/#map=14/48.7536/9.0367)
apart from the unsigned and generally unused E routes
This here is the big problem I'm seeing with implementing this. Taking a section of the M1 as an example, we have ref=M1 on the way and a relation with ref=E 13 on it, running concurrent. We can't not render the way refs.
One option is to slice up the way refs on ;, deduplicate with relation refs, and render the deduplicated refs. This would get a shield for both M1 and E 13 in the example above.
This would also reveal a particular class of mistake, where refs disagree between route relations and their ways. As an example, the Rodovia Washington Luiz has BR040 on some ways and BR-040 on the relation.
Does anyone have any other suggestions that will work in the M1 case I gave?
refs on relations aren’t supposed to include prefixes like “BR” or “BR-”. That’s what network is for; ref should just be “040”. The real problem is that the relation’s network isn’t guaranteed to match the prefix in the way’s ref. (For example, Ohio state routes are ref=SR ### on the ways and network=US:OH ref=### on the relations.)
Perhaps the test could be whether the relation’s entire ref (e.g., “040”) can be found anywhere in the way’s ref. If so, just use the already formatted way ref value. We wouldn’t have to make assumptions about spaces, hyphens, or how to shorten the network value (none of which would be a problem with graphical shields), or sorting for that matter. In other words, the way would be used as scaffolding, as it were, for the relation data. It’d be a compromise between the American goal of relying on route relations and the European practice of tagging ways instead.
If the map adopts a deduplication algorithm, entry-level editors like iD would need to present a consolidated ref field using the same algorithm. Otherwise, an inexperienced mapper would be left wondering about phantom refs.
refs on relations aren’t supposed to include prefixes like “BR” or “BR-”.
The documentation you linked doesn't have any examples of road route relations.
The examples I found in Germany, France, England, Brazil, Spain, Russia, Italy and Mexico all have ref tags that are not purely numeric and include prefixes.
2014-06-27 2:08 GMT+02:00 Paul Norman [email protected]:
This would fail in the region I showed. It would also fail on the other side of the tunnel. The only route relations for roads I saw were for the E road network.
In my area there are lots of route-relations so I thought they were common, looking at taginfo I saw these numbers: route=road 91000 ref=* and highway=* 4.7M
not sure how many highway ways are in the average route=road relation, the above relation is 51.6 highway+ref per route=road relation, which seems not too bad (just a gut feeling I admit).
Regardless of those numbers I agree with Martijn that rendering refs for route relations will encourage mappers to create those relations and will remove the incentive for people to duplicate the info on the ways.
@pnorman The obvious solution for the M1/E13 issue is that the E13 relation in the UK shouldn't be tagged with ref=, but instead admin_ref= or some similar tag used for unsigned, administrative-only numbers.
2014-06-27 12:22 GMT+02:00 Paul Norman [email protected]:
The examples I found in Germany https://api.openstreetmap.org/relation/21250, France https://api.openstreetmap.org/relation/1139312, England https://api.openstreetmap.org/relation/107076, Brazil https://www.openstreetmap.org/relation/62885, Spain http://www.openstreetmap.org/relation/76946, Russia http://www.openstreetmap.org/relation/2708563, Italy http://www.openstreetmap.org/relation/10256 and Mexico https://www.openstreetmap.org/relation/3232571 all have ref tags that are not purely numeric and include prefixes.
In Germany there are not many overlapping highway-road-routes, but only as long as you don't care for "U"(Umleitung= alternative roads in case of traffic jam / major accidents), but they do exist for small parts (aside from the E-Road network, which can also be expressed with an additional tag "int_ref"). Adding a character (e.g. "B"undesstraße, "A"utobahn, "L"andesstraße, "K"reisstraße, "U"mleitung) is mandatory to understand the type of road (maintainer), they will always be used. In Italy the situation is very similar (most common abbreviations are "A", "SS", "SR", "SP"). Then there are scenic routes (like "deutsche Weinstraße", "deutsche Alleenstraße") etc. which also are signposted, and which also do overlap with the main classification (which is indicating the maintainer).
@pnorman The obvious solution for the M1/E13 issue is that the E13 relation in the UK shouldn't be tagged with ref=, but instead admin_ref= or some similar tag used for unsigned, administrative-only numbers.
unsigned_ref. My concern is, are there roads with ref tags where they are in road route relations with a different ref and the ref on the way would not normally have a route relation created.
2014-06-27 12:52 GMT+02:00 Richard Fairhurst [email protected]:
@pnorman https://github.com/pnorman The obvious solution for the M1/E13 issue is that the E13 relation in the UK shouldn't be tagged with ref=, but instead admin_ref= or some similar tag used for unsigned, administrative-only numbers.
@richard: the common ref tag for "E" in continental Europe is "int_ref", but they are signed e.g. in Germany, so the situation is slightly different there. Still, using different tags in different countries for the same type of network would seem strange.
I looked at what we've got in the database for rendering route relations
- Route relations are present
- We know way vs. relation from
osm_id<0. - We don't have
type, but we do haveroute, so can work onroute=road. - A query like
select w.osm_id,w.name,w.ref from planet_osm_line w join planet_osm_line r on(st_within(w.way,r.way)) where r.osm_id=:rid and w.osm_id>0;seems to find ways that are a member of the relation- This fails for two ways that are identical where one is a member
- performance is going to be a bugger to solve
No way can have more than one ref (apart from the unsigned and generally unused E routes) - i.e. no "multiplexing" or "concurrency" - and each signposted ref is, in theory, unique within GB.
That seems to be false: the A6/A591 overlap.
Concurrency is certainly not a US-only thing. There are overlapping sections in the Netherlands, for example.
More on concurrency on Wikipedia.
In Germany there are not many overlapping highway-road-routes
Routes of "Bundesstraßen" (primaries) do also often overlapp. Example way. These routes (B196 and B173) take the same route nearly to the whole city of Chemnitz.
