Talk:Highway Directions In The United States
KristenK: How can I get in touch with Boppet? Not sure I'm comprehending the Role=forward section. (1) I want to make sure I'm understanding correctly that your usage of term "1-way way" means single-carriageway and "2-way way" means dual carriageway. Single-carriageway roadways carry both directions of a highway route. I am thinking that we can possibly designate north/east as the "forward" and "south/west" as the backward. If travel is against the "forward" (aka north/east) then it can be inferred the travel is going "southbound/westbound".
Boppet: Hello KristenK. I'm Boppet, aka Peter Davies at Castle Rock Associates in Portland Oregon. I found your (or Martijn's?) "Highway Directions in the United States" page and felt that it was really helpful. I'd been puzzling about how to represent what we at Castle Rock call posted "directionality" (North, South, etc. next to highway route number shields). So I edited your page (without realizing how new it was, sorry) to see if the OSM world would move closer to a solution that will work for Castle Rock and its primarily state DOT customers. (Our state DOT customers enter "traffic event" data into Castle Rock software that feeds real-time info and route guidance systems such as RDS-TMC and Google. Perhaps your Telenav system also handles real time event/incident data, too?)
By "2-way way" I mean a single carriageway road carrying 2-way traffic. I will edit the page again to try and be clearer. For posting directionality, personally, I like the role=east kind of approach that you show is the more common. However I'm not sure how to use it on a 2-way undivided road (Brit: single carriageway road). I suggest in my edit that the OSM forward direction of the way could be given role=east (say) to show that for drivers traveling towards the last node of the way, the signs would say "East". I suggest that we could infer that the backwards travel along the way would be posted as "West". But I'm not really happy about this, as our state DOT customers can probably find dozens of ways of posting roads illogically. Also, it's not a very intuitive solution, either. Do you have a method for recording posted directionality on 2-way single carriageway roads?
I've not previously taken part in Talk US, and I'm not so familiar with OSM community's ways of working, but I'll send an email to that site also, and see if I have better luck than you with our email servers.
KristenK: Single-carriageway roadways carry both directions of a highway route. I am thinking that we can possibly designate north/east as the "forward" and "south/west" as the backward. If travel is against the "forward" (aka north/east) then it can be inferred the travel is going "southbound/westbound".
Boppet: Kristen (and Martijn): I'm not sure what you mean here. We might both be suggesting the same thing for single carriageway ways, but I'm not certain. And even if we are, I'm getting gradually more sure that I don't like my own proposal! So I give another one below. But it's complicated and is probably new. :(
As a default, in many states, on highways that generally trend northwards and eastwards, the milepoints increase. Our Castle Rock applications (for state governments) need milepoints as well as posted directionality, as state police often report incidents by milemarker. But you don't need milepoints so much, if at all, I imagine, so that can probably wait for another discussion. There are many exceptions to the general rule that mean (I believe) explicit posting of "pointes kilometriques" (pk tag, with units in miles) will usually be necessary.
Of course 2-way single carriageway ways are directionally posted in both travel directions, e.g., North and (hopefully) South. So what should we say in OSM? The whole road should be posted in the same way (except on some beltways) irrespective of whether locally it is heading N, S, E or W in the positive (increasing milepoint) travel direction. But states don't always follow strict rules about which roads to post N-S and which to post E-W, even though AASHTO recommends basing this on the presence of an odd or even highway route number. Some legacy route numbers may go back even further than this decades-old recommendation, and states don't need to follow AASHTO rules if they choose not to.
My theory was that, since every OSM way has a forward and a backward direction defined by the node sequence in the way's definition, we would write "role-=east" in the relations of ways whose successive nodes are sequential west to east, meaning that the forward OSM direction of the 2-way single carriageway is posted as East. Or, if the nodes along a way happened to be listed from east to west, we would write "role=west" in the relation. We might be willing to guess that the opposite travel direction would be posted oppositely.
What I don't like about my proposal is that it's messy and hard to follow. There are 2-way single carriageway state roads like ID 21 from Boise to Stanley that comprise (about) 17 ways, with 13 being OSM forward from west to east and about 4 being OSM forward in the opposite travel direction (or do I mean south to north? It's not obvious. Ok, our ITD CARS system says it's posted N-S, with milepoints increasing northwards, as AASHTO would recommend too). The OSM relation (which currently doesn't exist) would need to show 13 members with role=north and 4 with role=south, just because some coder or algorithm originally entered the constituent ID 21 ways inconsistently.
Perhaps a better solution might be to reverse the 4 offending ways so all the ID 21 nodes are listed in the same travel direction? It seems as if you guys are using automated editing tools, a step we have yet to take here at Castle Rock. Perhaps you would be able to do this easily? Then each member's role would ideally need to say something like role:forward=north, role:backward=south. Or if we leave the ways as they are, 13 would need to say role:forward=north, role:backward=south; while 4 would need to say role:forward=south, role:backward=north.
This isn't very simple, but at least it's definitive. It would survive and conquer all signposting inconsistencies. Some beltways shift from being posted E-W to N-S, and I'm not sure that there isn't a section or two posted "E" one way and "N" the other. We would have to write role:forward=north, role:backward=east (assuming we were at the SW corner, and that OSM nodes happened to be listed clockwise around the beltway ways). Of course most US beltways are dual carriageways, so the issue of 2-way single carriageways would not actually arise ... But other roads may occasionally switch between N-S and E-W posting. Almost anything is possible.
My syntax in this proposal may not make sense, and I doubt there is a single way posted like this at present. So there must be a better way of posting 2-way single carriageway directionality ... isn't there?
Boppet: I had an idea during the night. I think it might be sufficiently simple and intuitive to answer the questions I asked up above. In particular, I asked how can we expand the role of a "way" member of a 2-way single carriageway highway route relation so that it shows the two posted cardinal directions, e.g., North and South, that appear on state route designation shields in the USA? My suggestion is that we expand what Martijn and KristenK have been coding so that we capture both posted directions that share a 2-way single carriageway, while also indicating which direction is which when you travel along the road. Below I show an example of a relation I just created for ID 21 (which had no previous relation defined in OSM). It comprises 17 2-way single carriageway ways joined end to end. However, on 13 ways the ways have OSM Forward heading generally northwards and eastwards, while on 4 ways the OSM node sequence is reversed, incrementing toward the south and west.
The relation captures which way the road is posted by listing the OSM Forward direction first (e.g., role="north ... for the first member) and the OSM backwards direction second (e.g., ...; south"/>) for the first member, whose OSM nodes are sequenced from west to east. (I'd like to have said from south to north, but this mountain pass road winds around every possible way during its 140 mile extent from I-84 near Boise to Stanley, ID. The first way is posted North but heads roughly ESE.)
Notice below that 4 ways have role="south; north" instead of role="north; south". This is because (as mentioned above) these four ways have been node-listed in OSM in the opposite direction from the other 13. The ITD directional signing is consistent, but ID 21 OSM coding is not. Rather than guess which way is north (hard to do in mountains), the relation below gives posted direction unambiguously for each of its member ways. Here is the new relation using the proposed role coding:
<osm version="0.6" generator="CGImap 0.3.1 (18603 thorn-03.openstreetmap.org)" copyright="OpenStreetMap and contributors" attribution="http://www.openstreetmap.org/copyright" license="http://opendatacommons.org/licenses/odbl/1-0/"> <relation id="3344440" visible="true" version="7" changeset="19109928" timestamp="2013-11-25T13:51:51Z" user="Peter Davies" uid="1238559"> <member type="way" ref="125630976" role="north; south"/> <member type="way" ref="210231982" role="north; south"/> <member type="way" ref="210231985" role="north; south"/> <member type="way" ref="13705751" role="north; south"/> <member type="way" ref="53130386" role="north; south"/> <member type="way" ref="53130382" role="north; south"/> <member type="way" ref="125630998" role="south; north"/> <member type="way" ref="125631005" role="south; north"/> <member type="way" ref="13694411" role="south; north"/> <member type="way" ref="13770102" role="north; south"/> <member type="way" ref="13770398" role="north; south"/> <member type="way" ref="34788083" role="north; south"/> <member type="way" ref="34788084" role="north; south"/> <member type="way" ref="34788087" role="north; south"/> <member type="way" ref="34788088" role="north; south"/> <member type="way" ref="13796450" role="north; south"/> <member type="way" ref="13794473" role="south; north"/> <tag k="network" v="US:ID"/> <tag k="ref" v="21"/> <tag k="route" v="road"/> <tag k="type" v="route"/> </relation> </osm>
If we ever encounter a road posted illogically with apparently conflicting directions, say where eastbound beltways turn northwards, we can handle the situation as follows. This shows OSM Forwards is posted North and OSM Backwards is posted East:
<member type="way" ref="xxxxxxxx" role="north; east"/>
I will tweak the wiki page now to match this approach while awaiting responses.
- If we were do add both cardinal directions on one way, we shouldn't have a space after the ";". We don't add a space when we enter the "ref" tags on the ways when there is more than one route on a way, so why do it here for the roles? -- rickmastfan67 (talk) 04:20, 27 November 2013 (UTC)
- Yes, thank you Rickmastfan67, I realized this too after I'd done it. I'm on travel at the moment but I'll fix it when I can. - Boppet 09:54, 27 November 2013 (UTC)
- After reading the replies on the Talk-US mailing list and some thought, I see the merits of Peter's approach of explicitly indicating the directions of the two-way/single carriageway roads using a forward/backward pair relating to the cardinal direction. As long as one understands the relationship between the node direction and the first and second value of the member role--delineated by a semi-colon--then it shouldn't be a problem to implement. Just my two cents. - KristenK 10:45, 27 November 2013 (UTC)
I removed this paragraph, I don't think it directly relates to the topic of directions, but if we can tie it up to the signposted cardinal directions topic I'm happy to be proven wrong! --Martijn van Exel (talk) 16:40, 5 December 2013 (UTC)
Posted Milepoints In most states, milepoints increase in the direction posted as East or North. However, milepoints sometimes jump, repeat, or even reverse direction due to legacy signing and the occasional re-designation of state routes. Also some states' signing of directionality changes at intervals around beltways, while the milepoints continue to increase. So recording posted milepoints in OSM must be separated from recording posted directionality. The posted direction of increasing milepoint values can be inconsistent.
removed alternate tagging paragraph
Other tagging strategies for directionality include:
- Using one relation per cardinal direction and tagging the entire relation?? This would be suitable for relations representing interstate routes. For instance, a relation representing Interstate 5 North would have a direction tag value of "north".
- Retain the legacy forward / backward member tagging on relations and infer cardinal direction from the physical layout of the route. However, I-10 E-W runs N-S through parts of Phoenix, as does I-94 in parts of the Twin Cities, and diagonal routes could equally well be posted N-S or E-W. We need to record which one it is, as well as which way is which.
"Posted Directionality of 2-way Single Carriageway Ways" section
There is a problem with that section. Sometimes, only one direction of a road is on a 2-way single carriageway way. An example that comes to mind right away that I have traveled is PA-60 in Crafton, PA.
Going NB (really WB but they didn't change the cardinal directions after the route was shorted because of I-376) on PA-60, going into Crafton, you need to turn right onto a one-way road to keep on NB PA-60 (StreetView). However, is you still go straight there, the opposite direction on the 2-way road is now just SB PA-60. Now, looking at the other end of the split highway (StreetView), you have both NB and SB split onto separate 2-way roads. (PA-60 relation in the Crafton area)
So, as you see, you can't always assume that if the highway only has a "role=north" tag on it, that the opposite direction is "role=south" automatically. -- rickmastfan67 (talk) 22:06, 20 December 2013 (UTC)
What direction roles should be used for beltway or other loop roads where cardinal directions aren't signed, such as Pittsburgh's Belt System routes? inner and outer? clockwise and counterclockwise? CW and CCW?
Tagging and non-English locales
The article mentions that roles for route relations should be marked with north, south, east, or west. But what about routes that are present with directions in non English speaking countries or locales? Two examples are Puerto Rico, where signs are marked Norte, Sur, Este, and Oeste, and on the border between Quebec and Ontario, where the signs change from English to French.
In these examples, should the language of the role match the language of the locale (mimicking the existing policy in place on Key:name), or should the names always be in English, regardless of where they are on the planet?
And even further, how should front end user applications expect to deal with this data to provide valid directions to the end user? Should those applications just return the value of the role variable, should they transliterate the English version? --Angela Morley (talk) 02:45, 28 February 2018 (UTC)