Render ref from route relationship

[matthijsmelissen]

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?

[matthijsmelissen]

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.

[matthijsmelissen]

The same holds for name's on relations.

See also https://trac.openstreetmap.org/ticket/2599,

[dieterdreist]

Am 03/giu/2014 um 00:09 schrieb math1985 notifications@github.com:

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

[skylerbunny]

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.

[pnorman]

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.

[skylerbunny]

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

[mvexel]

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/

[mvexel]

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.

[mvexel]

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.

[pnorman]

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?

[skylerbunny]

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.

[pnorman]

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.

[pnorman]

we have the case of dealing with route concurrency open in issue #508.)

508 is about pictorial signs, not concurrency

[mvexel]

On Thu, Jun 26, 2014 at 6:08 PM, Paul Norman notifications@github.com 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/

[pnorman]

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?

[1ec5]

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.

[systemed]

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.

[pnorman]

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.

[sb12]

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)

[pnorman]

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?

[1ec5]

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.

[pnorman]

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.

[dieterdreist]

2014-06-27 2:08 GMT+02:00 Paul Norman notifications@github.com:

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.

[systemed]

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

[dieterdreist]

2014-06-27 12:22 GMT+02:00 Paul Norman notifications@github.com:

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]

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

[dieterdreist]

2014-06-27 12:52 GMT+02:00 Richard Fairhurst notifications@github.com:

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

[pnorman]

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 have route, so can work on route=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

[matthijsmelissen]

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.

[Klumbumbus]

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.

[systemed]

No, Wikipedia is talking rot. The supposed "A6/A591" is simply the A591: see https://www.google.co.uk/maps/@54.274877,-2.765902,3a,75y,21.65h,92.6t/data=!3m4!1e1!3m2!1sz0ICKln6poNuszEasYtUAA!2e0 , https://www.google.co.uk/maps/@54.272723,-2.758914,3a,75y,320.77h,81.82t/data=!3m4!1e1!3m2!1sb1x1JcktbUIu3N4Df6mpIQ!2e0 , https://www.google.co.uk/maps/@54.308431,-2.758175,3a,75y,195.49h,81.52t/data=!3m4!1e1!3m2!1sPHUvOnku3Sl-B0Ag4W2a3w!2e0 , https://www.google.co.uk/maps/@54.309761,-2.763812,3a,75y,172.43h,83.94t/data=!3m4!1e1!3m2!1shVlzWFdOhBu1U2zzdgQ4Mw!2e0 , https://www.google.co.uk/maps/@54.298062,-2.759611,3a,75y,172.43h,75.13t/data=!3m4!1e1!3m2!1sdQ-PIcR2cPsvKzd4imCxJA!2e0 etc. The road is clearly signed A591 as would be expected, with A6 in brackets for the usual "leads to" signage. Similarly, at the https://www.google.co.uk/maps/@54.280274,-2.76669,3a,75y,181.98h,81.97t/data=!3m4!1e1!3m2!1s76O7FXUiRLuYbmTKKIEkyw!2e0 turn it's signed A590, with the A6 in brackets.

The fact that each road in the UK has no more than one number is extensively documented in SABRE etc.

[mvexel]

Concurrency is probably why the E-routes in the EU are done using relations. I can think of no other than historical reasons why this tagging convention would not propagate to other road networks.

@Klumbumbus - are route relations used in Germany for maintaining the numbered road networks? Or is it mostly refs on ways?

I see the challenge @pnorman raised with inconsistent use of the network tag. In the US, this is well defined, but I am curious if this just a lack of documentation?

On Fri, Jun 27, 2014 at 7:49 AM, Klumbumbus notifications@github.com wrote:

In Germany there are not many overlapping highway-road-routes

Routes of "Bundesstraßen" (primaries) do also often overlapp. Example way http://www.openstreetmap.org/way/44026067. These routes (B196 http://www.openstreetmap.org/relation/3422875#map=12/50.8289/12.9670 and B173 http://www.openstreetmap.org/relation/2105830#map=12/50.8239/12.9652) take the same route nearly to the whole city of Chemnitz.

— Reply to this email directly or view it on GitHub https://github.com/gravitystorm/openstreetmap-carto/issues/596#issuecomment-47346002 .

Martijn van Exel http://oegeo.wordpress.com/ http://openstreetmap.us/

[Klumbumbus]

@Klumbumbus - are route relations used in Germany for maintaining the numbered road networks? Or is it mostly refs on ways?

As far as I know, the refs are always on the ways (because this gets rendered atm). Route relations for primaries exist "often", for secondaries and tertiaries "less often". For some routes there is only the TMC relation and no proper route relation.

If the rendering changes from ways to relations I don't see a big problem for germany, since we have a strong community, which will create the missing route relations then.

[mvexel]

I suspect that will happen in most places - although there will be a fair amount of resistance from (route) relation haters... Which I understand fully, but I think it's time to get over that. Some logic is just too hard to capture adequately without them.

One hurdle may be editor support. I haven't used iD much, but I hear that relation support there is not so great. Perhaps for the better, people maintaining relations are more likely to be using power tools anyway.

On Fri, Jun 27, 2014 at 8:22 AM, Klumbumbus notifications@github.com wrote:

@Klumbumbus https://github.com/Klumbumbus - are route relations used in Germany for maintaining the numbered road networks? Or is it mostly refs on ways?

As far as I know, the refs are always on the ways (because this gets rendered atm). Route relations for primaries exist "often", for secondaries and tertiaries "less often". For some routes there is only the TMC relation and no proper route relation.

If the rendering changes from ways to relations I don't see a big problem for germany, since we have a strong community, which will create the missing route relations then.

— Reply to this email directly or view it on GitHub https://github.com/gravitystorm/openstreetmap-carto/issues/596#issuecomment-47350670 .

Martijn van Exel http://oegeo.wordpress.com/ http://openstreetmap.us/

[skylerbunny]

One hurdle may be editor support. I haven't used iD much, but I hear that relation support there is not so great

I'm one of those weird people who started with iD and kind of never branched out much into other tools. I can tell you that once you know how iD handles them, relations work fine and are reasonably maintainable in the tool. (Others may work BETTER in this regard, sure, but I can in fact modify and work with them in iD.) In fact, iD could probably be programmed to throw warnings in cases where a ref is on a way and a relation, causing a conflict.

[1ec5]

pnorman wrote:

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.

Yikes, I didn’t realize there was such a discrepancy between the standard in the U.S. versus elsewhere. The consensus on talk-us has been for numeric refs and fully qualified networks (see the Interstate and U.S. route relation listings), but then again we seem to rely on route relations a lot more than these countries. The only point of contention on talk-us has been where to put banners like “ALT” or “TRUCK” (ref vs. modifier vs. network).

[pnorman]

Yikes, I didn’t realize there was such a discrepancy between the standard in the U.S. versus elsewhere. The consensus on talk-us has been for numeric refs and fully qualified networks (see the Interstate and U.S. route relation listings), but then again we seem to rely on route relations a lot more than these countries.

This is one of the dangers of doing tagging for not purely local matters on a local list.

I do not see a way to convert what the wiki documents for the US to a rendered shield. There is no consistent standard for the network tag, so we couldn't use it without a lot of country-specific logic. network is fine for pictorial shields since you need country-specific shields, but the design seems to have ignored text shields

[pnorman]

There is no consistent standard for the network tag

I decided to look at the US practice of using a colon. Of the 3.3k distinct values for network outside the US (not having network LIKE 'US%'), 234 (7%) have a colon. When counting relations, not distinct values, it's 24k/172k (14%).

[pnorman]

So, after having done some research and thinking about the SQL side, I'm inclined to leave this open to resolve the technical side even through it will take some time to get the US relation tagging consistent with the rest of the world.

Regardless of if we slice and combine or use refs on ways as a fallback, we need a way to do matching between ways and relations. Doing this isn't hard (for me, at least). Doing this in a performant manner is.

I did some checking. Route relations are only present in planet_osm_line, not planet_osm_roads, which immediately is a performance hit. A partial index WHERE route='road' AND ref IS NOT NULL AND osm_id<0 could help here.

Next, we have the choice of finding relations for ways or finding ways for the relations. The latter has rendering advantages (they come pre-merged) but has performance implications: route relations can be very long. We also have the issue that it makes it more difficult for GroupSymbolizer and concurrencies (not a current issue) because the concurrencies will change along the length of the relation linestring.

The above dictates the strategy, now to write some non-trivial SQL

[mvexel]

On Fri, Jun 27, 2014 at 2:23 PM, Paul Norman notifications@github.com wrote:

I do not see a way to convert what the wiki documents for the US to a rendered shield. There is no consistent standard for the network tag, so we couldn't use it without a lot of country-specific logic.

If we're just out to duplicate the rendering styles we already have but using data from the relations instead of the ways, then country-specific logic should be avoided, obviously. If countries want nice country-specific shield rendering, they can set up their own tile server, like Toby did for the US (concurrency hell here: http://openstreetmap.us/~toby/shields.html#14/39.7834/-86.0322)

Or at least that used to be the answer. Other map providers can do country specific things, so why can't we?

Martijn van Exel http://oegeo.wordpress.com/ http://openstreetmap.us/

[pnorman]

In the common case, we've got this (1d roads)

Any way's linestring is within any parent relation's linestring.

It, however, is not obvious that this is always the case. osm2pgsql splits long linestrings for performance reasons.

You can have a scenario where there is a break in the relation linestrings from distance splitting, but not a break in the way linestrings.

Relation linestrings in brown, way linestrings in green, breaks indicated with arrows. (I 5 in Washington.

On the other hand, limiting linestring length to 100 Mercator km does help with performance, particularly once you start manipulating the linstrings.

[1ec5]

pnorman wrote:

So, after having done some research and thinking about the SQL side, I'm inclined to leave this open to resolve the technical side even through it will take some time to get the US relation tagging consistent with the rest of the world.

On second thought, it’s entirely appropriate that the U.S. omits prefixes in relation refs while Europe and Brazil include them. Relation refs hold whatever’s on the signage. In the U.S., that would generally be a plain route number; in Europe, that would include a prefix. Either way, the goal is for renderers to avoid having to parse the relation ref for something to put in a pictoral shield. So I don’t think it’s necessary to change any tagging at all. (And we’ve had this discussion before on talk-us. The current usage is intentional, it avoids edit wars over hyphens, and it’ll make implementing #508 a bit easier.)

[matthijsmelissen]

Relation refs hold whatever’s on the signage. In the U.S., that would generally be a plain route number; in Europe, that would include a prefix.

It's unfortunately not that easy. There are also some European countries, such as Germany and Poland, where the shields don't contain the prefix.

[pnorman]

On second thought, it’s entirely appropriate that the U.S. omits prefixes in relation refs while Europe and Brazil include them.

Then the textual shields will say "405" instead of "I 405".

[skylerbunny]

It's unfortunately not that easy. There are also some European countries, such as Germany and Poland, where the shields don't contain the prefix.

The base assumption, however:

In the U.S., that would generally be a plain route number; in Europe, that would include a prefix.

...already assumes we're at least continent if not country aware of where the route relation in question is. The 'network' tag provides exactly this information, so we would know which to do. Or, if we don't want to program that logic into the renderer, we could always have the tag 'include_prefix' yes/no on a route relation, default assumed to be one or the other.

[1ec5]

pnorman wrote:

Then the textual shields will say "405" instead of "I 405".

Which would be unfortunate. But then we can add the three rules required for implementing #508 in the U.S., one for each shield-fill (white, black, and yellow), and it won’t matter anymore.

[pnorman]

We have to be able to render generic text shields, and #508 is more a follow up to this than the other way around.

[1ec5]

Yes, I’m in total agreement. I just meant this work will make #508 trivial to fix, hopefully in short order. :-)

[pnorman]

I took a first pass at rewriting the low-zoom query for refs. This is just the 20 minutes of query-writing collection of my thoughts so far

(
  SELECT 
    COALESCE(r.geom,h.way) AS way, COALESCE(r.ref,h.ref) AS ref -- if r.ref is not null then r.geom is also not null
      FROM (
        SELECT 
            way, 
            ref
          FROM planet_osm_roads
          WHERE highway in ('motorway','trunk','primary','secondary')
            AND way && !bbox! -- The only spatial check that limits the results
          ) AS h
        LEFT JOIN (
          SELECT 
              ST_Collect(way) AS geom, -- Is this the right way to do this? Do we need to ST_Dump first? All we can safely assume is that way is a linestring
              ref 
            FROM planet_osm_line 
            WHERE ref IS NOT NULL 
              AND h.way && way -- Is a ST_Intersects faster? Is this even necessary with the join condition?
              AND route = 'road' 
              AND osm_id < 0 -- relations
            GROUP BY osm_id
          ) AS r
          ON (ST_Within(h.way, r.geom))
      WHERE r.ref IS NOT NULL or h.ref IS NOT NULL
  ) AS roads_text_ref_low_zoom

Some thoughts in-line.

One obvious flaw with this is that it will return a linestring for the relation as many times as there are ways in that relation in the bbox. I could probably do a SELECT DISTINCT to eliminate this, but I won't know until I start performance profiling if it's better to do that or to let mapnik try to render the shields, but not do anything because they're exactly the same. It might cause issues if we start trying to re-position to avoid collisions.

Any thoughts?

[pnorman]

select ref,highway,length from
(
  SELECT 
    COALESCE(r.geom,h.way) AS way, COALESCE(r.ref,h.ref) AS ref, -- if r.ref is not null then r.geom is also not null
    h.highway, char_length(COALESCE(r.ref,h.ref)) as length
      FROM (
        SELECT 
            way, ref, highway
          FROM planet_osm_roads
          WHERE highway in ('motorway','trunk','primary','secondary')
            AND way && !bbox!
          ) AS h
        LEFT JOIN (
          SELECT 
              ST_Collect(way) AS geom, -- Is this the right way to do this? Do we need to ST_Dump first? All we can safely assume is that way is a linestring
              ref 
            FROM planet_osm_line 
            WHERE ref IS NOT NULL 
              AND route = 'road' 
              AND planet_osm_line.way && st_expand(!bbox!,100000)
              AND osm_id < 0 -- relations
            GROUP BY osm_id,ref
          ) AS r
          ON (ST_Within(h.way, r.geom))
      WHERE r.ref IS NOT NULL or h.ref IS NOT NULL
  ) AS roads_text_ref_low_zoom

This appears to work, but using st_expand(!bbox!,100000) only works with prior knowledge of the depths of osm2pgsql splitting, and is a decidedly sub-optimal way, particularly as zooms increase. I can't do planet_osm_line.way && h.way, so it looks like I need to completely restructure the query.