Trying again ... ---------- Forwarded message ---------- From: Peter Davies <peter.dav...@crc-corp.com> Date: Sun, Nov 24, 2013 at 10:46 AM Subject: Separate relations for each direction of US & State highways. To: talk-us@openstreetmap.org
Kristen and Martijn, I've not posted here before so I hope I'm doing this adequately well. I saw Kristen's outreach to me on the Talk page of Martijn's http://wiki.openstreetmap.org/wiki/Highway_Directions_In_The_United_States. so I replied to it there. I very much like the approaches that Telenav is taking and wanted to elaborate them on the wiki to see if we are in the same place. For me, it makes sense to post role=east etc. for directional carriageways of dual carriageway roads, as Telenav has been doing. Certainly role=forward doesn't seem to tell me anything, if it's a 1-way carriageway. If traffic can only use a way in one direction then it's obvious that the posted highway route must follow a different way for the other travel direction. Am I missing anything about the uses of role=forward? (It's entirely possible!) What concerns me, though, is this. I'm still not sure if we have a solution to posting cardinal directionality (North, South, etc., with highway number shields) on 2-way single carriageway state roads. I floated an approach on the wiki page but I'm not sure that I really like it. I hope someone has a better solution without having to create thousands of duplicate relations for the opposite travel direction of single carriageway and mixed single/dual carriageway highways. I apologise/apologize if I've upset some OSM community courtesies by floating possible solutions on the wiki. Like Telenav, my company (Castle Rock Associates, Portland, OR) would like to adopt and follow a consistent solution that can work throughout the Americas, or anywhere else on Earth where cardinal directions are posted on highway shields/direction signs/route confirmation signs. Peter Davies, aka Boppet *---------- Forwarded message ---------- From: Kam, Kristen -(p) <kristenk at telenav.com <https://lists.openstreetmap.org/listinfo/talk-us>> Date: Wed, Nov 20, 2013 at 3:41 PM Subject: RE: [Talk-us] Separate relations for each direction of US & State highways. To: "Van Exel, Martijn" <martijnv at telenav.com <https://lists.openstreetmap.org/listinfo/talk-us>>, James Mast <rickmastfan67 at hotmail.com <https://lists.openstreetmap.org/listinfo/talk-us>> Cc: talk-us <talk-us at openstreetmap.org <https://lists.openstreetmap.org/listinfo/talk-us>>, "Zontine, Chris -(p)" <chrisz at telenav.com <https://lists.openstreetmap.org/listinfo/talk-us>>, "Lemberg, Vladimir" <vladimirl at telenav.com <https://lists.openstreetmap.org/listinfo/talk-us>>, "Yu, Haifeng (Chris)" <haifengy at telenav.com <https://lists.openstreetmap.org/listinfo/talk-us>>, "Martijn van Exel (m at rtijn.org <https://lists.openstreetmap.org/listinfo/talk-us>)" <m at rtijn.org <https://lists.openstreetmap.org/listinfo/talk-us>> James+Community, I am the editor you called out in your e-mail on Monday. This is my response. Please note although I can receive messages posted on the talk-us mailing list, I cannot post to this list at this time. I am running into technical difficulties and I am working with Ian Dees to resolve them. For now, Martijn will just forward this message to the list. A fellow Telenav OSM editor and I have been making edits as an effort to solve the problem of the lack of cardinal direction information on highway route relations within the United States. Our reasoning is that the lack of cardinal directions for highway routes affects the guidance/routing quality. As you mentioned in your November 17, 2013 message to the talk-us mailing list, you would like routers to properly tell the direction of the highway folks would need to turn onto. It can be safe to say that you and I agree that this is a problem that would need to be solved. We took a look at the attributes of the existing highway route relations within the United States. We found that individuals employed one of the two following methods in adding cardinal direction information: For route relations entirely comprised of ways representing one direction of the highway route, the route relation had a direction=* tag value of north/south/east/west. The case of the values varied, but individuals set cardinal direction values to the direction tag of the relation. For route relations that are comprised of ways representing both directions of a highway (dual carriageway) or bi-directional road segments, individual editors set the member role to a cardinal direction the way represented. We reviewed the OSM wiki page (http://wiki.openstreetmap.org/wiki/Relation:route <http://wiki.openstreetmap.org/wiki/Relation:route>) on route relations and found these values were consistent with the cardinal direction Member roles values listed on said wiki page. When looking at the data in more detail, we found a preponderance of relations that were edited to use the member role method cited above more than the direction=* tag method. Since both methods were employed to handle the setting of cardinal direction information to highway route relations, we decided to incorporate both methods in our editing routine. Depending on the situation, of course. We considered splitting existing to smaller relations based on their direction--as discussed in the talk-us mailing list--but we adopted the member role/direction=* tag method because it is less expensive (who wants to create more relations?), less complicated, and consistent with the existing editing practices we observed. A handful of route relations not edited by us that are consistent with our editing routine include: http://www.openstreetmap.org/browse/relation/215687 <http://www.openstreetmap.org/browse/relation/215687> (user StellanL) http://www.openstreetmap.org/browse/relation/228529 <http://www.openstreetmap.org/browse/relation/228529> (user ToeBee) http://www.openstreetmap.org/browse/relation/156379 <http://www.openstreetmap.org/browse/relation/156379> (user dchiles) http://www.openstreetmap.org/browse/relation/155931 <http://www.openstreetmap.org/browse/relation/155931> (user NE2) http://www.openstreetmap.org/browse/relation/335542 <http://www.openstreetmap.org/browse/relation/335542> (user NE2) You have mentioned for the need to incorporate cardinal direction information into existing routers. That got me thinking, “Are there existing routing engines that use existing cardinal direction information?” I took a look at the OSRM and the Mapquest Open routing engines. Both use OSM data as the base map and for routing/guidance. The reason why I only tested both is due to the fact that I do not own a smart phone (brick phone for the win!). Please take a look at the cases, which are listed in a word document that is attached to the following Evernote: https://www.evernote.com/shard/s366/sh/8bad0862-ace2-4085-bebd-2b9f986a915e/7ecb2153773925234db05370c5cb6ea8 <https://www.evernote.com/shard/s366/sh/8bad0862-ace2-4085-bebd-2b9f986a915e/7ecb2153773925234db05370c5cb6ea8> To summarize my investigation: The OSRM routing engine does not provide highway direction information into their guidance. However, the Mapquest Open routing engine appears to incorporate cardinal direction member role values for interstate or state highways route relations, that are ENTIRELY comprised of motorways, into their routing/guidance. In summary, the point I am trying to make is that we’re not re-inventing the wheel in terms of relation tagging conventions or setting member roles values of existing relations’ members. Merely, we are incorporating existing practices into our routine. The cases cited in the Evernote demonstrates that other OSM data consumers’ are making the mapping practice observations we have been making. And they are incorporating this information into the construction of their OSM-driven products. That’s pretty much it. I look forward to your and other talk-us subscribers’ response. Best, Kristen* *Hey all, Reading through this I see that most are in favor of avoiding dividing relations more than necessary: no separate relations for directions, especially not if the geometry is the same for both. That leaves the question of how to tag cardinal directions? As I said before, I think the role tag is suitable for this. It's already used pretty widely (with around 100k ways having a cardinal direction as the role tag in a relation), documented (https://wiki.openstreetmap.org/wiki/Route#Members <https://wiki.openstreetmap.org/wiki/Route#Members>) and it replaces the forward / backward role values that are not particularly useful or meaningful. I created a stub of a wiki page that we could use to describe the preferred tagging in more detail: http://wiki.openstreetmap.org/wiki/Highway_Directions_In_The_United_States. <http://wiki.openstreetmap.org/wiki/Highway_Directions_In_The_United_States.> (The current content is geared towards using the member role tag, but this can be changed depending on the outcome of this discussion.) Here at Telenav we can commit to doing much of the work completing the cardinal direction tagging, and we're eager to get started, but I do want to ensure that we're following best practices.* *James, This does warrant an explanation for sure. Kristen is one of my colleagues here at Telenav and we discussed best editing practices for cardinal direction information here internally. The plan was to take the discussion to this list before proceeding on any kind of scale. I managed this poorly and this did not happen yet. For this I apologize! I have made sure that we take a step back and have this discussion first before proceeding. Back to the topic at hand. We discussed options for adding cardinal direction information to route relations. We considered but dismissed splitting route relations at direction breaks and adding direction= to each relation - to my mind, this would make for a contrived relation hierarchy for a relatively simple information element. The remaining viable alternative to my mind is then to edit the role tag to reflect cardinal direction. This makes sense to me for a number of reasons: leveraging a tag that already exists and does not contain particularly useful / relevant values (forward / backward); the practice is already documented and pretty widely used, and lastly, it's transparent and explicit. More generally on relation maintenance, I think we may need some better tools to monitor / repair broken relations. I know there are a few tools out there (I link to some of them on the relation pages) but I am wondering if we would benefit from some kind of automated relation integrity checking? If so what would that ideally look like? If there's interest, will see what we could do here to build something. Looking forward to hearing your thoughts. Martijn *
_______________________________________________ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
