[Talk-us] Relation member order/structure; best effort worth it?

[stevea]

>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.

Except for Interstates/freeways/highways, such "middle tier" road 
route relations seem like a sort of data structure that OSM neither 
has nor needs, but instead, you (and your business) need.  (I make no 
value judgement on the benefit of an "operational public information 
system" and I welcome the possibility that OSM might provide data 
input for them, but, to wit, discussions to get there are notably 
difficult).  OSM DOES have route relations, and this topic started on 
how those might be "better ordered."  WHY they might be better 
ordered has yet to be answered (I only speculate that further 
downstream algorithms might prefer data which are better ordered than 
more poorly ordered).  But it does appear that ordering of elements 
in relations is a large topic that has large implications if done vs. 
not done.  There appear to be reasons to do so, there appear to be at 
least the "manual" (human, think-about-it) way and the JOSM-automatic 
way (which I'm unfamiliar with).

>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?

I don't hate the idea, I like it, but of course I'd like to "play 
with it" when it is more ready.  I would want to better understand 
why a particular order was chosen over others, see if routing 
algorithms (a VERY common use for geographic data) are more efficient 
with one vs. another style of ordering, etc.

>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.

Peter, this doesn't initially offend or seem like a bad choice, 
though it does certainly grease the skids for your purposes.  There 
isn't anything wrong with that FOR YOU, but I believe it is incumbent 
upon us (OSM, as a project) to consider this in the longer term and 
wider application.  It seems a difficult problem, there appear to be 
multiple solutions where one solution for a particular application is 
better than another, and it is difficult to strictly enforce "less 
pure data" getting written into OSM at the end of the day.  Plus, 
what we mean by "pure" or "preferred" or whatever is far, far from 
specific right now.

>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.

Volker told me that the public transit folks in Italy have come to 
the inescapable conclusion that at least two relations are required 
for each bus/tram/train route:  the "inbound" and the "outbound."  I 
concur, as if you try to capture this semantic on a single route, but 
with syrup-y syntax, like inbound_stop and outbound_stop, you're 
still identifying two entities (inbound and outbound), you're just 
putting it into the syntax with some sugar.  These distinctions 
between syntax and semantics are often quite difficult as OSM evolves 
around the world:  we have SOME good solutions, we have SOME bad 
compromises, we have SOME right-on-target.  I, too, don't wish to see 
"needless" proliferation of relations, but instead wish to achieve a 
logical/mathematical "sweet spot" of the perfect harmony of syntax 
(data structure, tagging) and semantics (what we mean to 
convey/represent in the real world BY the data structure/tagging). 
This has proven difficult, especially with the exceedingly rich 
semantic entities in the whole world and in many countries with 
differing laws and such.  OSM's  free-form tagging allows us to go in 
an infinity of directions, so imposing structure upon this 
(especially after-the-fact of creating massive data) is necessarily 
tangled up with the struggle between legacy-of-the-old vs. 
designing-for-the-new.

>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.

There are multiple solutions, some better than others for particular 
purposes.  That previous sentence is "a better" way (maybe not "the 
best") that I am able to respond to that right now.

>Whew! So I guess I'm asking, shall we just give up on consensus 
>building and see what happens by natural selection?

I wish I could say definitively what is "best."  I am trying to 
listen, as it appears many of us are doing, but it just swirls and 
swirls, without seeming like it is achieving escape velocity to an 
ultimate solution.  Yes, there will always be a process of natural 
selection going on with OSM data.  Yes, it can be (IS!) difficult to 
achieve consensus, especially when "the math" (or "geometric logic") 
is complex and there are multiple possible solutions, some of which 
are "sweeter" for one application vs. another.  I don't mean to sound 
like I'm simply wringing my hands in frustration, but I'm not sure 
what is next here.  These are difficulties, and talk-us is a fairly 
thin pipe in which we communicate about them (though it's not 
impossible to do this here).

SteveA
California


>
>
>
>On Sun, Jan 12, 2014 at 1:21 AM, stevea 
><<mailto:steveaOSM at softworkers.com>steveaOSM at softworkers.com> wrote:
>
>A sidelong topic to "separate relations."
>
>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).
>
>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).
>
>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?
>
>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?
>
>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.
>
>A lot of the conversations here are an attempt at agreement among 
>structure and tagging.  Good for us.
>
>SteveA
>California
>
>_______________________________________________
>Talk-us mailing list
><mailto:Talk-us at openstreetmap.org>Talk-us at openstreetmap.org
><https://lists.openstreetmap.org/listinfo/talk-us>https://lists.openstreetmap.org/listinfo/talk-us
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/talk-us/attachments/20140112/c3882109/attachment-0001.html>