Talk:Interstate Highway relations

Network Value

Why not make the network value "Interstate" instead of "I"? It's more readable to humans. --Ezekielf 15:40, 12 April 2009 (UTC)

• That was my first thought but then saw United_States_roads_tagging#Tagging with relations (proposal). I started this page to track the Interstate relations and get the discussion rolling on how to tag them.--Nickvet419 18:35, 12 April 2009 (UTC)

Interstates w/ more than 1 relation...

Is there going to be any troubles is an interstate (or any other highway) has more than 1 relation (for instance I-70 or I-80)? 25or6to4 21:31, 13 April 2009 (UTC)

Probably not once the concept of super-relations becomes more formalized. --sargas 21:53, 13 April 2009 (UTC)

Also, it's a situation we're hopefully going to see less of, now that we're coordinating our efforts on the wiki. – Minh Nguyễn (talk, contribs) 01:57, 14 April 2009 (UTC)

Egads... I just saw I-90. A relationship for each state from the west end? Mythdraug 19:52, 31 August 2009 (UTC)

As someone who created some of these relations, a bit of quick background: I-90 already had two or three relations before I added Wyoming, Washington, Idaho & Montana. It therefore seemed logical to create new relations to avoid conflicts. With JOSM it is possible to select all ways belonging to a relation and edit them (for instance adding a new relation), so I checked that merging these would not be a serious editing problem. However, further consideration suggests that the idea of a single relation for I-90 is impracticable for several reasons: 1) relation members should be ordered (more or less impossible to achieve with current editors), and the number of members of non-ordered relations will significantly affect eventual manipulation of order; 2) relations are restricted to (I think) 2000 members. Once ways start getting split for bridges etc., the number of members shoots up. Most interstates are still pretty much a single way across each county, but even just fixing a short stretch through a city can generate tens of members. The latter is a show-stopper to the idea of having a single relation for the entire route. I hope that chunking by state will keep them within the limit. SK53 20:39, 31 August 2009 (UTC)

No worries for me, hope you took no offense to my comment. But thanks for the detailed explanation. I just picked up I-90 as I was tagging I-80 across Ohio. Took the relation form what was suggested by Potlatch. Then, when I came here to link back out to the analyzer to see if I had missed anything, I saw the number of I-90 relations.Mythdraug 22:04, 31 August 2009 (UTC)

Unfortunately, none of the renderers nor Potlatch supports super-relations (relations that contain only relations), which would be the ideal solution here. – Minh Nguyễn (talk, contribs) 11:21, 2 September 2009 (UTC)

Honestly, do any of the renderers even support route relations? --sargas 15:42, 8 September 2009 (UTC)

At the very least, OpenCycleMap supports bike route relations. :^) I can't think of a general-audience renderer or router that makes use of road relations, except for a proof-of-concept involving highway shields. – Minh Nguyễn (talk, contribs) 06:29, 9 September 2009 (UTC)

I see the proposal to use addr:state=* shows a list of states. What do you think about creating one relation per state and then using another relation (a super-relation) to combine all of these?--Elyk 04:07, 14 April 2009 (UTC)

• Not that I have anything against that idea, but I think the states are needed to uniquely identify the aux. routes (i.e., there are four I-275's) since these should not be repeated within a state.

We have been discussing Interstate relations on talk-us, and the developing concensus seems to be that interstate relations should be on a state-by-state basis. I have proposed the following new language on relations:

Avoid relation proliferation, if possible. Interstate Highway relations should be on a state-by-state basis, e.g. I-90 in MA, I-90 in NY, I-90 in PA, and so forth. If a suitable relation already exists for the route you are tagging, you can reuse the existing relation in your area. In Potlatch, do a relation search on the existing relation's number.

--nfgusedautoparts 10:18 7 September 2009 (UTC)

I've begun work on I-24 in TN using the new schema from the Talk-US discussion, but it looks like neither the renderers nor the relationship analyzer can handle super-relationships yet. I'm also concerned that route proliferation will break the current table structure here in the wiki. Does anyone feel that super-related Interstates should be split out into a seperate table scheme for their respective numbers? --DiverCTH 00:30, 27 September 2009 (UTC)

Bannered routes

In my opinion, "FUTURE" routes should be tagged as state=proposed. There's no wiki page on it yet, but Relation:route suggests it, and renderers and editors have supported it for quite some time. As for the other bannered routes, they don't really belong in separate networks, as they're really offshoots of a main highway, the same way an I-510 is related to I-10. In Ohio and probably other states, bannered state highways are given suffixes such as SR 48T (for State Route 48 Truck). I think it's reasonable to do the same for national routes, so US 90 Business would be tagged as network=US:US, ref=90 BUSINESS. If you're concerned about renderers making the badges too long, that's what modifier is for: ref=90, modifier=BUSINESS. – Minh Nguyễn (talk, contribs) 00:26, 27 May 2009 (UTC)

Multiple Same-Direction (Express/Trucks) Ways

For roadways that have separate ways for express/truck-only lanes, like the New Jersey Turnpike 189809 189809, I've been adding the separate ways as an additional "north" and "south" way within the relation. Is there a policy for this? Johnjreiser 14:44, 12 August 2009 (UTC)

Probably better to use a separate relation, with modifier=EXPRESS or TRUCK. Since Potlatch doesn't display modifiers in the relation menu, you could mark the express route ref=90X or somesuch, to avoid confusion. But there's no policy on this as far as I'm aware. – Minh Nguyễn (talk, contribs) 10:23, 13 August 2009 (UTC)

Cleanup needed

While editing I-80 near the I-99 junction (http://osm.org/go/ZcSP5Ip), it seems that there are two sets of ways sharing nodes. One extended slightly beyond appearing as a separate way, but when I added oneway to it, a second set of arrows appeared beyond where I thought it started. Deleting nodes along the duplication in potlatch affects both ways. I am unsure how to resolve. Mythdraug 13:05, 26 August 2009 (UTC)

This often happens when splitting long ways (such as Interstate highways) in Potlatch. Instead of deleting individual nodes, see which version is correct, then delete the incorrect one. In Potlatch:

1. Select a shared node and press / to alternate between the two superimposed ways.
2. Pan around to figure out which one is longer. (You may have to zoom out a bit.) Note that the shorter way might be correct if these ways were created as the result of a split; the longer way might overlap a bridge or something down the way.
3. Select the incorrect way and press Shift+Delete to delete it. If Potlatch gives you an error about someone else modifying the way, don't select the download option, just restart Potlatch.

 – Minh Nguyễn (talk, contribs) 05:20, 27 August 2009 (UTC)

Deletion of road tags

I saw that some people are deleting name- and ref-tags from the roads when they made it a member of a relation. In my opiniom this is absolutely not neccesary. Also these tags are used for rendering most maps. So I think this practice should be stopped! --Moonwashed 20:09, 1 October 2009 (UTC)

These tags are made redundant by the relations. We don't want or need redundant data in the database. Please don't add them back. Your time is better spent making the renderers support the relations. What's the point of creating the route relations if renderers don't support them?--Elyk 04:19, 2 October 2009 (UTC)

That doesn't make it necessary to delete the ref tags, though. You could determine what city or state a POI is in without is_in=*, but we haven't deprecated that tag and removed any uses of it. Often, mappers are placing human-readable route IDs like "SR 2" in ref and more structured, less ambiguous information in the relation itself. Until the renderers and routers fully support relations, there's no harm in keeping existing refs. – Minh Nguyễn (talk, contribs) 11:40, 2 October 2009 (UTC)

is_in=* is not a good example. What relation deprecates it? You could look at boundary relations and try to see if the object is within the bounding polygon. But you have to throw a lot of processing horsepower at that problem, so it's not easy to do a search, for example, for all highways in a city. What happens where a way crosses the boundary? Is it in or not? Now if we had an is_in relation where all of the highways, POIs, etc. were members, then that relation would deprecate the is_in tags. (Not that I like that idea for is_in=*, but that's exactly how the route relations are set up.)

I'm under the impression that name=* is meant to be human readable, and ref=* is meant to be machine-readable and therefore consistent on all highways. Making ref=* human-readable or stylized is a step backwards in that respect. It is not worth my time to keep track of the extra name=* and ref=* tags that are left on the ways, especially when the relation is supposed to make those obsolete.--Elyk 23:48, 2 October 2009 (UTC)

You're right, it's not a good example. But "SR 2" (the road's reference) wouldn't go in name, "Foo Road" (the road's name) would. We don't currently have any way of indicating to routers what the "stylized" reference would be. Perhaps in the future the renderers will hard-code that information for each state and county, but that's not practical for something like CloudMade Maps at the moment. – Minh Nguyễn (talk, contribs) 08:49, 3 October 2009 (UTC)

These tags will be made redundant, perhaps, some time in the future. What I observe now is that on the Slippy Map ref-symbols are more and more disappearing in some parts of the US and the map looks poorer than before every day. So, yet the tags are not redundant as the Slippy map and mkgmap rely on these. --Moonwashed 15:48, 2 October 2009 (UTC)

All I can say to that is Don't tag for the renderer. Removing them puts pressure on the renderer developers to support the relations, so hopefully we will see the fruits of our labor sooner rather than later.--Elyk 23:48, 2 October 2009 (UTC)

Tagging for the renderer is absolutely fine if you're tagging correctly. If a way belongs to the "State Route 2" relation and you tag it ref=SR 2, that's not incorrect. I don't even think it's necessary, but at the same time it shouldn't be necessary to remove it. Are the developers such unreasonable people that we need to remove data in order to convince them to add a new feature? – Minh Nguyễn (talk, contribs) 08:49, 3 October 2009 (UTC)

Don't just hope, vote[1]. Interestingly, for Osmarender, route relation support is as simple as flipping a switch (showRelationRoute=no right now). Never mind, apparently it has problems. – Minh Nguyễn (talk, contribs) 09:04, 3 October 2009 (UTC)

Relations and Directions and States

Looking at the list of existing relations, it seems some are direction specific, and some are for both directions, and indicate using role=(north|south|east|west)

I've seen suggestions for both methods in several places.

My opinion is that a separate relation should be used for each direction. Here's why: Sometimes, a section of Interstate is also a different route, be it a US (non-Interstate) Highway, or a State Route. Okay, fine. However, sometimes that other route is marked as a different direction. I can't think of a true example at the moment, though I know I've seen it on the West Coast, I-5 (a North-South highway) may share some length with an East-West highway. Using a role on the way in this case doesn't work; there's no simple method to know to which designation it applies (well, ok, Interstate numbering scheme may help there...) Using role=north;east would just add to the ambiguity.

Someone else mentioned above that relations are limited in length to 2000 ways. One solution that seems to be in use is to use a separate relation for each state along the long Interstates, such as I-70... and for only those states that need it. Again, some ambiguity: what's the deciding factor that a state should get its own relation? How about just always giving each state its own relation every time?

Super-relations may be used to relate the two separate direction relations together. This super relation should probably be the same one that relates the different state relations together when a single relation would have too many ways.

So... Is there an advantage to using one relation for both directions, besides just dealing with fewer relations? Any reason each state shouldn't have its own relation, at least for those parts not already started? I'd like some input before I start in on adding relations to Interstates (and US highways, for that matter, though that would be a different discussion page!)

Granack 08:02, 4 October 2009 (UTC)

Regarding directions, that's just an argument against placing direction information on the way itself. To clarify, what we're denoting here as role is not a tag on a way; it's an, erm, relation between a way and the relation it belongs to. Potlatch displays each role on the same row as a relation in the key/value list.

Ohio has plenty of examples where an east/west highway is multiplexed with a north/south highway. In those cases, we've been entering roles according to the signage on the ground. So 39197425 39197425 belongs to I-71 as north but US 52 as east. No problem. In fact, the role approach can in some cases provide more information than the separate relations approach. A loop Interstate will usually switch between north/south and east/west four times. You could have "CW" and "CCW" relations, but that doesn't help the user know where the road starts being signed as northbound etc. (Of course, none of this helps when no router or renderer supports relations in the first place...)

All this is probably temporary to some extent: once super-relations are supported by enough editors, we can start joining together arbitrary numbers of relations in hierarchies.

 – Minh Nguyễn (talk, contribs) 11:48, 4 October 2009 (UTC)

Ah, thanks for explaining the "role" and the example... I thought the role was just a tag assigned to the way, and didn't realize it could be assigned to the way's relationship like that. And thanks for updating the page with the same info for other new users! - Granack 16:39, 4 October 2009 (UTC)

There's no reason to include state abbreviations in the roles of relation members. Multiple members can have the same role, and the state information can be placed in a state-specific subrelation or on the way itself using the addr:state=* tag. Also, relation-checking tools recognize the cardinal directions now, but other ad-hoc roles may have much less support. – Minh Nguyễn (talk, contribs) 07:58, 9 November 2009 (UTC)

I-86 in NY

I have completed the relation for I-86 in New York for those sections which I am sure are properly part of the interstate system. There are two sections of NY 17 tagged as I-86 which I'm pretty sure are not yet formally part of the Interstate system, one is from Chemung to Waverly along the PA border, and the other is in the vicinity of Middletown NY. The work to upgrade the stretch near Middletown is due to be completed this winter, any formal designation as I-86 would come several months (at least) later. Can anyone speak to why these segments are labeled I-86 right now? Given the doubt, I have omitted them from the new relation. nfgusedautoparts 17:25, 14 November 2009 (UTC)

I have now learned something about the criteria for designating highways as interstates. it would seem that to designate a chunk of NY 17 as interstate, not only must it meet standards, but one end must terminate at another interstate, and the other end must terminate at a route of "regional significance". so some sections of future I-86/current NY 17 that have I-86 ref tags are probably prematurely labeled. i will look into this a little more but i'm inclined to go and redo the tags to lift the premature I-86 designations nfgusedautoparts 04:02 10 December 2009 (UTC)

I-376 in PA

Just linking an article as justification for adding PA I-376. http://www.dot.state.pa.us/penndot/districts/district11.nsf/7580f0e72f1809df852570a70047899b/c1b1fb590f4c687a85257666006eb39e?OpenDocument Mythdraug 17:14, 4 January 2010 (UTC)

Is it signed to I-80 yet? --NE2 07:52, 5 February 2010 (UTC)

From what I've heard, it's pretty much fully posted except on the part that the Pennsylvania Turnpike controls. Check out this link: http://surewhynotnow.blogspot.com/2010/04/more-photos-from-pa-60-to-i-376.html --Rickmastfan67 11:34, 21 April 2010 (UTC)

WikiTable Code Cleanup

My knowledge of WikiTable code is very basic - can someone re-code I-24 and add relation 331981 as I-24 Westbound in KY? Thanks. --DiverCTH 04:01, 20 November 2009 (UTC)

And 331986 is Eastbound.--DiverCTH 04:31, 20 November 2009 (UTC)

Easy way to assign roles

If you have a relation that has no roles assigned and you want directional roles, here's an easy way:

1. Click the "a" link next to the relation
2. Make sure it's in two pieces, and copy the comma-separated list of ways for one piece
3. In a text editor, replace ", " with "|id:" and add "id:" to the beginning
4. Load the relation and its members in JOSM, and paste the list into the search box (with the regex box checked)
5. Determine which direction is now selected and assign the role
6. To select the other direction, search for -selected child ref=".*I X.*"

--NE2 07:52, 5 February 2010 (UTC)

Status of two-digit Interstates

Most of the two-digit relations are now complete. The only ones that need major work, mostly adding dual carriageways, are:

• I-25 in northern New Mexico
• I-35 in northern Minnesota
• I-39 in northern Illinois
• I-40 in Knoxville
• I-44 in Oklahoma and Missouri
• I-64 in West Virginia
• I-73 and I-74 in North Carolina
• I-77 in West Virginia
• I-79 in West Virginia and southwestern Pennsylvania
• I-81 in West Virginia and southern Pennsylvania
• I-84 in Oregon
• I-85 in Montgomery
• I-90 in Spokane

Otherwise both directions are tagged with a relation.

Would anyone object if I merged the uses of separate directional relations into one with directional roles? --NE2 16:09, 7 February 2010 (UTC)

I believe there was a consensus in the mailing list about 6 months ago that there should be a separate relation per direction per state. --DiverCTH 18:30, 7 February 2010 (UTC)

That seems silly - can you link to the discussion? --NE2 01:30, 8 February 2010 (UTC)

There was one thread in April that specifically addressed the Interstate system and another in September that discussed divided highways (AKA dual-carriageways in the EU).

I read through the latter discussion (the former was almost two years ago) and there doesn't seem to be any consensus. In any case, we should come to consensus here; this is already one step removed from the map database, and there's no reason to go elsewhere to come to consensus on what should be here. My main reason for wanting to merge is that this makes it easier to verify that a relation begins and ends in the right place; you only have to load one map for both directions. It's also easier in general to deal with fewer relations, and splitting by state where necessary should keep sizes manageable. --NE2 05:24, 8 February 2010 (UTC)

This is right now discussed on the talk-us list. I'd suggest you take part of that discussion. Nakor 15:18, 8 February 2010 (UTC)

I'm not going to sign up for a third place to discuss the content of a second place (this wiki) which governs the main place (OSM). --NE2 15:41, 8 February 2010 (UTC)

Thanks for providing the link though. There seems to be some exaggeration and panicking ("merging all of the states with 2 relations per interstate back into 1 relation"), as well as tagging for the renderer ("I use the ref on the relation when building maps for my Garmin to add highway shields to the map.") I was hoping to reduce inconsistencies in the various guidance pages, but if consensus building all takes place in these various back-channels, I truly will get no input until I make the changes, and then be reverted. --NE2 15:49, 8 February 2010 (UTC)

It seems most people in the OSM community value the mailing lists over the wiki. If you want some feedback, I would definitely go there. Nakor 18:40, 8 February 2010 (UTC)

Formatting

Let's, once and for all, come up with a standard of formatting these. There are two issues:

1. When and how do we split?
2. What goes in the various fields?

As for the first question, it's generally easier to deal with fewer relations; the only problem is when they get too big. I'd like to know if there are any benefits to having relations separated by direction. I've seen several for combining directions with roles:

• It's easier to verify integrity. There are two parts to this check: using the analyzer to see that it's in one piece, and then loading the relation on the slippy map to check the ends. The latter is particularly easier when both directions are combined, since you only need to zoom to each end once. (Yes, I realize that if superrelations are ever fully supported this will be moot, but we can revisit the question then.)
• It's easier to tag (see above). This is a minor issue, since it's just as easy to then split in two, and only matters when creating relations (or doing major cleanup).

Now, for the fields. The page currently says the following for I-83 (I've never seen this exact method followed):

• name=[blank]
• network=US:I
• ref=83

This makes it hard to edit in JOSM, since the ref is shown in the relation list when there is no name, and so Interstates get sorted between other types of routes. There are two solutions to this:

1. Add a name, which begins with I and includes the state and direction if applicable
2. Add that detail to the ref

I don't really have a preference one way or the other, but we should be consistent. --NE2 03:23, 9 February 2010 (UTC)

The recent change

I'm partially reverting DiverCTH's recent change in which he says that one relation per direction is preferred. There's no such consensus anywhere I can see, including the recent talk-us discussion.

We also need to figure out how best to tag the relations. Following the guideline as it is now, every relation for a route will have the same ref and no name. This means that in JOSM and Potlatch there's no way to distinguish them at a glance. (Yeah, I know, don't tag for the renderer editor, but when there's more than one way of doing something, we should do what makes our job easier.) --NE2 08:18, 10 February 2010 (UTC)

If nobody replies, I'm going to change it to the following:

• name=I 83 (details if not the whole route, such as "I 83 (PA northbound)")
• ref=I 83

--NE2 14:07, 13 February 2010 (UTC)

I've asked for some of the other members of the talk-us and tagging lists to weigh in on this. --DiverCTH 04:55, 14 February 2010 (UTC)

Regarding the ref field (and yes, I know it's the chicken-and-the-egg question about "tagging for the renderer") - one of the programmers on the tagging list has written a Custom Highway Shields renderer that generates highway badges based on the ref field - in your example network=US:I; ref=I 83 would render an interstate badge with I8. --DiverCTH 01:09, 15 February 2010 (UTC)

And what does it do for a relationless piece of highway tagged with ref=I 83? --NE2 12:32, 15 February 2010 (UTC)

Please, don't put a name tag on there if it does not really have one (like "JFK Highway"). We don't need to repeat the ref tag in the name. --Mjulius 14:52, 16 February 2010 (UTC)

What do you suggest for the ref tag then? If it's just "I 83" with no name, all the I-83 relations look the same in the editors. --NE2 16:52, 16 February 2010 (UTC)

You can use the is_in tag to differenciate between them. Nakor 18:09, 16 February 2010 (UTC)

I know there are various ways to distinguish. But do any make it easy to do so in the editors? It doesn't sound like much, but when you have twelve I-95 relations loaded in JOSM, and they all say "I 95 (xx members)", you're not going to know which is which without opening the details for each one at a time. This isn't tagging for the editor so much as tagging to make editing possible. --NE2 19:07, 16 February 2010 (UTC)

Another avenue could be to open a request at JOSM so that it displays alittle bit more. Nakor 01:55, 17 February 2010 (UTC)

Sure, but would they really change it to use one specific tag that only U.S. road relations use? Sounds like a nonstarter. --NE2 02:11, 17 February 2010 (UTC)

Not sure about the fact that it only applies to the US. Anyways I am only giving you suggestions to avoid tagging for the editor. Nakor 21:59, 17 February 2010 (UTC)

Well, we'd have to figure out what tags we want to JOSM to show. is_in wouldn't necessarily work, since then one relation for a long route would display all the states. Might it make sense to have something like relation_name that describes the relation rather than the elements? --NE2 01:10, 18 February 2010 (UTC)

Last Spring I created relations for most of the CA freeways following the exact method NE2 says above that has never seen followed (one relation per direction, e.g., type=route,route=road,network=US:I,ref=5,direction=N). I've relied on the data being in that format for various projects. Recent edits to I-80 have altered the format (using roles to define direction, adding the network identifier to the ref) and broken my queries. I don't have strong feelings regarding format beyond wanting a consistent standard that I can rely on so I can query my local copy of the database to get a single line geometry for each direction of the major freeways and highways in California. If the standard is to define direction using roles and ref=I 5, so be it, but I don't want to go edit all the CA relations only to have things revert back to one relation per and ref=5. --Sdtoooc 02:00, 23 February 2010 (UTC)

If I did move any away from compliance with this guideline, I apologize, and I thank you for reading and following it when creating relations (minor quibble: you probably shouldn't use abbreviations like direction=N, especially when the signs say north). If everyone had done that, maybe there would be a sort of disambiguation tag that the editors recognize. The earliest relations I dealt with in the course of other editing used, I believe, the same ref as the ref of the underlying ways, and I noticed that that made a lot of sense, so when I started working on relations and read this page, I didn't read carefully enough to notice that the specified ref was just the number. --NE2 02:49, 23 February 2010 (UTC)

Ticket opened: https://josm.openstreetmap.de/ticket/4596 --NE2 02:56, 23 February 2010 (UTC)

I-69 IN @ I-64

I happened to see that somebody asked a question about this route if it was posted @ the I-64/I-164 interchange on the main page. Well, whoever you where who asked that question, it is indeed fully posted there. Check out the following link for pictures (I didn't take them): http://www.aaroads.com/forum/index.php?topic=1726.msg51136#msg51136 --Rickmastfan67 11:54, 21 April 2010 (UTC)

Future Interstates

Just wanted you guys to know if you haven't been paying attention to North Carolina, there is a new way they are posting the Future Interstates. Instead of the "stand-alone" shields that the example shows on the I-69/73/74 lines, they have begun to post all the routes on BGS style signs on the side of the highway (when there is more than one route). Examples here: http://web.duke.edu/~rmalme/i7374seg101201dap.jpg http://web.duke.edu/~rmalme/i73840sign1w.JPG http://web.duke.edu/~rmalme/i74seg51214c.JPG NOTE: They are doing this too on normal Interstates (http://web.duke.edu/~rmalme/gl208n.jpg), so it isn't a Future only thing.

They have also posted (where there are stand-alone shields) "FUTURE" tabs above normal Interstate shields. My guess there is because NCDOT was hoping to post it as a full Interstate right away, but was denied by the FHWA. http://web.duke.edu/~rmalme/i7374108as.JPG

So, the "example" shown on the main page needs to be updated on the new tactics that are being deployed so an entire route that is legit as a Future Interstate will be able to be done correctly.

Comments? --Rickmastfan67 12:03, 18 May 2010 (UTC)

Splitting by state?

It seems to me that some routes, like I-66 and I-86, should not be split by state, since there's so little in one state-equivalent (here, DC and Pennsylvania). Of course there's no way to define exactly when we want to split, but is there any objection to changing "Interstate Highway relations should be on a state-by-state basis" to "Interstate Highway relations should usually be on a state-by-state basis"? --NE2 00:33, 20 May 2010 (UTC)

Well, with I-86, I think it's worth wild. Just look at the future for that route. I-86 in NY is going to keep growing. As of right now, the combined total for the segments in NY is 412. While the route is separated into EB/WB, the number is going to just continue to climb in the future with new interchanges, bridges over something as I-86 continues to gobble up NY-17. Because of that, it would make it harder, and harder encase any work would need to be done on the PA segment. Now, if there was, say, just a small segment in PA (less than a mile) and only 2 or 1 segments (each direction for a max total of 4), I could see it being merged. But PA has about 7 miles worth of I-86 (will grow a little bit in the future, but that's another can of worms) with a total of 16 ways (that number grew from what it was previously because I found a few missing bridges). --Rickmastfan67 01:27, 20 May 2010 (UTC)

16 ways (on average 8 per direction) is not much at all. And what do you mean when you say it will grow? --NE2 01:53, 20 May 2010 (UTC)

Around Exit #60 when NY-17 dips into PA. Thought you would know that. ;) --Rickmastfan67 02:16, 20 May 2010 (UTC)

Are you seriously suggesting making that part of the Pennsylvania relation? That would be incredibly pointless. --NE2 02:31, 20 May 2010 (UTC)

I didn't say I was. I was just pointing out that I-86 "technically" was going to be extended in PA. ;) --Rickmastfan67 02:39, 20 May 2010 (UTC)

Hidden Interstates

I'm just curious, why do we have a set of relations for the Alaska Interstates? They are all hidden Interstates and it goes against what has been done for other hidden Interstates in the lower 48 which is to ignore them and not create relations for them. -- rickmastfan67 06:48, 5 January 2011 (UTC)

I don't know, but you could change ref to unsigned_ref. --NE2 16:14, 5 January 2011 (UTC)

It'd be nice if renderers would support symbol=no for this situation. – Minh Nguyễn (talk, contribs) 10:53, 6 January 2011 (UTC)