<div dir="ltr"><div>I am very interested to see Paul Johnson's OK relation completion spreadsheet, as I'm trying to make a business decision on whether to use relations when importing OSM data into into our state DOT traffic information applications. These apps are neither navigation nor mapping, but share some characteristics with navigation in that we want to use OSM data to describe incident locations in plain English (or French, Spanish, German, ...) rather than travel directions in plain English, etc. For this we need the signposted cardinal directions in countries that follow AASHTO style route numbering practices with cardinal direction plates (North, South, East, West, or the same in French or Spanish).  Mostly I believe these countries are in the Americas, though I'd love to hear from anyone who knows of other national or regional examples.<br>
</div><div><br></div><div>From my viewpoint, a US crash is "On OK 165 northbound at Chandler Road." Currently it looks (from the OK spreadsheet and from my own impressions elsewhere) as if state road relations are still too far from completion for use this year in operational public information systems. And on named, un-numbered urban arterials, no-one has even started  to talk of creating route relations. Our OSM import algorithms will need to find all the OK 165 ways (or 44th Street, Phoenix ways) and assemble them automatically in an upstream to downstream order. We'd have to do that anyway in Europe and the rest of the world where no highway route relations exist, so it's probably the way we should go here in the Americas.  Does anyone know if the Europeans (of which I'm one, oops) have any plans to create route relations?  I have found none while in UK, NL, D, A, CH, I and F this past two weeks, but perhaps I didn't look hard enough.</div>
<div><br></div><div>It may be possible for my proposed OSM importer to generate automated OSM relations as an output from that "downstream sorting" process, but perhaps that would spoil a lot of mappers' fun at weekends and evenings?  We could also create automated relations for other countries, I suppose, but I'm not sure whether or not we should.  I'd like to hear thoughts on this.  We are still some months (or longer) away from reaching this capability, by the way, and don't even need to go there if you all hate the idea. We could just ignore OSM route relations and effectively create our own, internally, as we currently would have to in the other 80% of the world.  Our relations would be ordered lists of ways, single track, with no branches or loops, in linear reference order.  Does anyone want them (or not want them) exported back to OSM?  </div>
<div><br></div><div>Steve, you talk about manual v. automated sequencing of relations. I've experimented with JOSM ordering, most recently yesterday on Paul's Muskogee Turpike in OK, and previously in other states.  The sequencing that emerges has not been particularly easy to understand.  Sometimes a tiny branch way has been (in my view, wrongly) labelled with the state route ref, and the JOSM algorithm picks it as the start point for the whole route  For me, a better algorithm would probably begin with the most southerly or easterly unconnected way and build a series of linked collections of ways sorted by typical US milepoint positive direction, S to N or E to W. Anyway as long as mappers can adopt any order they like for ways in relations, my OSM importer will have to make its own sort decisions to get the ways in topological (linear reference) sequence from end to end.  Would you support rules or guidelines for preferred sequencing of way members of relations?  What do we do with breaks, branches, loops, alternating single and dual carriageways, etc, etc.?  My starting suggestion is that we use a sequence based on increasing linear references from 0.0 to the top end of the road, but that rule alone would not solve every situation.</div>
<div><br></div><div>Paul, you don't like directional roles on the member ways of route relations, and I think your solution is to create three relations per route.  I would call these directions positive (increasing linear reference, corresponding loosely with increasing milepoints), negative (the reverse) and both directions (the parent).  We would post the cardinal directions using tags for each whole directional relation. However where the Muskogee Turnpike turns from E-W to S-N, or has some even more complex deal such as E +ve and N -ve, the 3-relation method will fail. We could further extend it by breaking the relations at the turns (strictly, at the directional posting changes), having maybe nine relations for a complete rectangular beltway (2 on each of the N, S, W, and E sides, plus a parent) but Martijn and Kristen Kam have wanted to avoid relation proliferation. This is why Martijn's firm (and OSM mappers) have adopted a hybrid system, as I understand it, using posted directions on roles for complex routes, and posted directions on directional relations for simple Interstates like I 5.  </div>
<div><br></div><div>Right now I don't think Talk-us has been able to solve the directional roles issue.  I guess we are left with a hybrid situation where some routes have directional roles on member ways, while others have direction tagged for the whole directional relation.  If there is no consensus about how to sort the order of relations, and vastly more manual work to do to create them all, perhaps we should just auto-create separate relations for every route in both directions, with separate directional relations whenever the route turns from N-S to E-W?  At least then everyone agrees about the sequence of members in the relation; you start at the beginning and end at the end in the direction of traffic movement.  If there are breaks, where the route does not exist, the relation can span over them and they will show up in JOSM's relation editor by a little gap in the wiggly line.  It seems like using a sledgehammer to crack a nut, but it may be easier to automate and check than more elaborate schemes that use complex directional roles on the member ways of alternating single/dual carriageway routes.</div>
<div><br></div><div>Whew! So I guess I'm asking, shall we just give up on consensus building and see what happens by natural selection?  </div><div><br></div><div>Peter <br><div><br></div></div></div><div class="gmail_extra">
<br><br><div class="gmail_quote">On Sun, Jan 12, 2014 at 1:21 AM, stevea <span dir="ltr"><<a href="mailto:steveaOSM@softworkers.com" target="_blank">steveaOSM@softworkers.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
A sidelong topic to "separate relations."<br>
<br>
Volker and I just shared some email about how he uses JOSM automation to order relation elements, whereas I make some effort to "smarten them up."  This includes getting more, rather than fewer "route is ordered" messages from JOSM's relation editor's hover text.  It also includes "putting the list into a smaller sized set of well-ordered sub-routes" as a strategy.  (On my part, when I am manually re-ordering relation elements, especially when the route has branches and/or loops).<br>

<br>
My argument is that "downstream algorithms" (whether by human effort or software robot) are often going to try to smarten up this route relation to a single path (or a subset of that, like sorting algorithms do with subsets of sorted lists).<br>

<br>
Fascinating, no?  Does "smartening up" a data structure like "closer to a single path" (or close via many sorted sub-paths) tend towards coding for the renderer?  Or downstream software routing algorithms? Is there anything wrong with trying to write neat, better-organized data?  If we can, why wouldn't we?  (Cost of time/effort, perhaps). But even if only entities during the "while" can use it, and even if the relation in the meantime is essentially ephemeral?<br>

<br>
Conversations like these help us hone in on a certain truth, or at least efficiency, yes?  In short, shouldn't we try to write neat data (if it isn't much extra effort)?  How can we get a nice "Pow!" for that buck?<br>

<br>
We use shared data, after all.  The data I write today get used tomorrow, even though they might not next week.  But they might get used smartly (with less effort, quicker...) if I invest a bit of smarts right now.  Maybe that is automation (JOSM plug-in, bot, DWG consensus...) maybe that is a bit of human manual effort where it might make a difference.  Where does it make a difference?  OSM can be a deep place sometimes.<br>

<br>
A lot of the conversations here are an attempt at agreement among structure and tagging.  Good for us.<br>
<br>
SteveA<br>
California<br>
<br>
______________________________<u></u>_________________<br>
Talk-us mailing list<br>
<a href="mailto:Talk-us@openstreetmap.org" target="_blank">Talk-us@openstreetmap.org</a><br>
<a href="https://lists.openstreetmap.org/listinfo/talk-us" target="_blank">https://lists.openstreetmap.<u></u>org/listinfo/talk-us</a><br>
</blockquote></div><br></div>