[Talk-us] Relation member order/structure; best effort worth it?
peter.davies at crc-corp.com
Sun Jan 12 13:18:18 UTC 2014
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.
>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.
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?
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.
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
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.
Whew! So I guess I'm asking, shall we just give up on consensus building
and see what happens by natural selection?
On Sun, Jan 12, 2014 at 1:21 AM, stevea <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.
> Talk-us mailing list
> Talk-us at openstreetmap.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Talk-us