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

Sat Dec 21 20:52:43 UTC 2013

This would match how people usually talk about things like I-465 around
Indianapolis, ignoring all the other routes that are also routed along it,
but it doesn't work quite so well when there are co-signed routes that
persist for long distances where people refer to the paired name. I think
Highway 1-9 in New Jersey, which is both US 1 and US 9, is the main
example, but Highway 12-18 in Madison, WI (US 12 and US 18) also comes to
mind.

Eric

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

> 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
>>>
>>
>>
>
> _______________________________________________
> 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/a37be094/attachment.html>