[Talk-us] Prioritizing multi-banded route designators (multiple overlaps) on ways: the "Principal route designator" concept

Sat Dec 21 20:21:59 UTC 2013

A further thought in favor of using the way ref tag simply to indicate the
"principal route designator", leaving any multi-banded secondary routes
that share the way to be defined only in the relations, is that we would be
making the US more consistent with road numbering and mapping practices in
other countries.

In the UK, for example, "multi-banding" does not occur because the
Department of Transport allows numbered roads to have breaks (gaps) where
they follow other routes.  For example, the M62 from Liverpool to Leeds and
Hull no longer exists across the Manchester M60 Ring Motorway section.
 Drivers follow M62 from Liverpool, then take the Manchester Ring Road M60,
and then pick up the M62 again across the Pennines to Leeds and Hull.  In a
similar example on the primary route system, the A49 joins with the A5
around the Shrewsbury bypass, and then separates and strikes off north
again after a few miles.  This approach is universal in the UK, and is also
standard practice in many other countries.

In the UK and elsewhere, the shared section is identified by a single
"principal route designator".  Important secondary UK designations can be
shown on green primary route signs, e.g., Oswestry A5; Leominster (A49).
 This is interpreted as "A5 changing to A49" for Leominster.  On UK maps of
all kinds, only A5 is marked on the common section. Thus, OSM currently
tags ways on the common section simply with ref A5.  We could do the same
here in the US if we swapped out US 202;ME 11;ME 17;ME 100 for just US 202
in the way ref.  (As it happens, only US 202 IS currently coded on Western
Avenue in Augusta, and perhaps we should leave it that way?)

I believe that US state DOT practices of multi-banding might be made more
user friendly if we could focus on the "principal designated route" in the
way ref tag.  It doesn't really help many drivers to know that I 80 in
parts of Wyoming is also US 30.  My thoughts are that the Interstate system
rightly swamps out "noise" from older transcontinental routes that have
little travel significance in the 21st century.  It could be that these
secondary sign shields are an unwarranted expense that may gradually fade
away.  But those who still want to show secondary banding would be able to
do so using the route relations.

We would also be eliminating the practice of cramming multiple data
elements into a single tag. Personally I'm not a purist about such things,
but I've seen some people shudder at the current U.S. "way ref tag"
practices of listing route refs one after another in a single data field.

Peter

On Sat, Dec 21, 2013 at 10:46 AM, Peter Davies <peter.davies at crc-corp.com>wrote:

> I think it useful to spin off this topic from the long and still
> unfinished debate about directional roles in relations.  I hope it can be
> agreed more quickly than the cardinal directional roles issue!
>
> The question is how to handle US roadway routes that are double, triple or
> even quad-banded, having multiple route designators.  Some OSM mappers call
> this topic "route overlaps."  I might call it "information overload." On
> most maps, renderers simply show ALL the shields. But is it helpful to have
> roads peppered with conflicting information about the route number?  Who
> gains by knowing that Western Avenue, Augusta, Maine is US 202, ME 11, ME
> 17 and ME 100?  Isn't this really confusing and unhelpful for most map
> users?
>
> Now, if it's confusing on a map, just think how confusing it is in a
> navigation system or a traffic event info system.  "Look out for a crash on
> US 202 eastbound / ME 11 northbound / ME 17 northbound / ME 100 eastbound
> (Western Avenue) in Augusta."  We need to know which route designator is
> the most important one, and to use mainly or only that one when talking to
> drivers.
>
> This is not something that OSM needs to make up. The principal designator
> should the top shield, left shield or top-left shield on traffic signs.
> State DOTs and police also face this same problem, and every multi-banded
> route section in states with which I work already has an "official"
> principal designator.  We need a way of capturing this in OSM for use in
> nav systems and info systems, as well as (perhaps) for ridding simple maps
> of route shield clutter.
>
> Martijn van Exel and perhaps others have suggested that we should use only
> relations to define route designators on ways, and not way ref tags.
>  However  I can't see how the relations alone can indicate this hierarchy
> of route designators on a way.
>
> As an example, let's look again at Augusta, ME, where Western Avenue is
> quad banded as US 202;ME 11;ME 17;ME 100.  I've just listed these routes in
> the logical "highest system, lowest number first" sequence.  I see that the
> current OSM way ref tag by the Senator Inn (just east of I-95) only says US
> 202, though I know from visits and from working with MEDOT that all four
> shields exist on the ground.  The OSM relations currently include all four
> of the routes, but do not help us to prioritize the designators.
>
> To check out what MEDOT and the State Police think about Western Avenue's
> principal designator, I just logged into Maine's state CARS system
> (Condition Acquisition and Reporting System -- which we build and maintain
> for MEDOT here at Castle Rock) and it suggests that Western Avenue is "top
> posted" for MEDOT users as ME 100, not US 202.  Of course I then looked at
> Google.  No, I'm not going to copy it.  But this is fair usage, I think,
> for research on this general problem. Google says Western Avenue is ME 100
> or ME 11 on Streetview.  But the Google Map shows all four shields.
>
> I currently believe that Western Avenue "officially" has ME 100 as its
> principal designator, and not the apparently "higher classification" US 202
> route designation.  However, the signs have US 202 at the top left of a
> "square" of four shields.  So I personally I would continue to treat this
> road as principally US 202 in OSM, replacing the present way ref tags that
> say "US 202" with "US 202;ME 11;ME 17;ME 100".  But in doing so I'd be
> adding to map clutter unless we build simple info systems that focus only
> on the first named (principal) route designator.
>
> I guess a more simple solution (always worth considering!) would be to use
> the way ref to show ONLY the principal (first) signed designator, and to
> cover the secondary route designations using the relations. This would
> avoid info info duplication between ways and relations (at least on
> multi-banded ways), and would automatically clear up map clutter of
> confusing shields on most OSM based maps.  Those who care about all the
> secondary designations could get them from the relations.  We could "keep
> it simple and stupid" for drivers.  The way ref would convey only the
> "Principal route designator."
>
> There are other examples of the idealized "highest system, lowest number"
> rule not being used. I 35 and I 80 north and west of Des Moines IA have the
> principal designator "I 80", not "I 35". I 80 determines the milemarkers
> and the exit numbers on this common section.  Looking at the milemarkers
> (and exits, on freeways) is one way in which OSM mappers can determine the
> state DOT's principal route designator.
>
> ****
>
> Finally as an aside, I think the OSM (bad?) habit of missing off the "US"
> or "I" or "ME" classification in relation (but not the way) refs perhaps
> means we don't know that Western Avenue is US 202 (as against ME 202)
> unless we look at the way ref as well as the relation ref.  Currently I
> don't think the relation ref alone can tell us the type of shield on which
> the route number is written.  I believe it would be better if relation refs
> and way refs were written consistently, as US 202 (etc.) and not just 202
> as we currently see in relation refs.
>
> Peter
>
>
>
> On Thu, Dec 5, 2013 at 9:20 AM, Martijn van Exel <m at rtijn.org> wrote:
>
>> Richard - true. It's sort of a chicken vs egg situation. As long as
>> there is no clear use case for one or the other, both practices will
>> remain in use. That's why I was so excited to see work continue on the
>> shield rendering which uses the refs on the relations. As I mentioned,
>> at Telenav we also pretty much solely rely on the relation refs for
>> the route numbers (and the relation member roles for the cardinal
>> direction, if we can come to a consensus about that.) These things may
>> help us converge on one way of doing things.
>>
>> On Sat, Nov 30, 2013 at 3:09 PM, Richard Welty <rwelty at averillpark.net>
>> wrote:
>> > On 11/30/13 4:57 PM, Paul Johnson wrote:
>> >
>> >
>> > On Sat, Nov 30, 2013 at 12:57 PM, James Mast <rickmastfan67 at hotmail.com
>> >
>> > wrote:
>> >>
>> >> Peter, it would just be for the relations.  It would stay the current
>> >> status-quo for the ways using at all times the "ref & unsigned_ref"
>> tags
>> >> (see I-394 example below).
>> >
>> >
>> > I can't wait until we can finally kill this dinosaur.  Refs, as they're
>> > presently tagged on ways, almost always apply to the route instead of
>> the
>> > way.  And not to mention they're just a pain in the butt to maintain
>> > properly where multiplexes exist, something that works cleanly in
>> relations.
>> >
>> > we're kind of stuck with ref on the ways until the data
>> > and data consumers come up to speed. there are a lot
>> > of route relations still to be built in the US.
>> >
>> > richard
>> >
>> >
>> >
>> > _______________________________________________
>> > Talk-us mailing list
>> > Talk-us at openstreetmap.org
>> > https://lists.openstreetmap.org/listinfo/talk-us
>> >
>>
>>
>>
>> --
>> Martijn van Exel
>> http://oegeo.wordpress.com/
>> http://openstreetmap.us/
>>
>> _______________________________________________
>> Talk-us mailing list
>> Talk-us at openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-us
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/talk-us/attachments/20131221/65cd8084/attachment-0001.html>