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:stevea...@softworkers.com>stevea...@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@openstreetmap.org>Talk-us@openstreetmap.org
<https://lists.openstreetmap.org/listinfo/talk-us>https://lists.openstreetmap.org/listinfo/talk-us
_______________________________________________
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us
