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 <[email protected]>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 > <[email protected]>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 <[email protected]> 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 <[email protected]> >>> wrote: >>> > On 11/30/13 4:57 PM, Paul Johnson wrote: >>> > >>> > >>> > On Sat, Nov 30, 2013 at 12:57 PM, James Mast < >>> [email protected]> >>> > 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 >>> > [email protected] >>> > https://lists.openstreetmap.org/listinfo/talk-us >>> > >>> >>> >>> >>> -- >>> Martijn van Exel >>> http://oegeo.wordpress.com/ >>> http://openstreetmap.us/ >>> >>> _______________________________________________ >>> Talk-us mailing list >>> [email protected] >>> https://lists.openstreetmap.org/listinfo/talk-us >>> >> >> > > _______________________________________________ > Talk-us mailing list > [email protected] > https://lists.openstreetmap.org/listinfo/talk-us > >
_______________________________________________ Talk-us mailing list [email protected] https://lists.openstreetmap.org/listinfo/talk-us
