[Talk-us] Separate relations for each direction of US & State highways.

Sat Jan 11 23:37:53 UTC 2014

Paul,

One of the things that Martijn and I agree needs to be possible is for
routes to change directional posting part-way along. This commonly happens
on beltways like that around Minneapolis St-Paul, that around Indie, and on
AZ Loop 101 and 202 here in Metro Phoenix.

For my part, I also feel we need to accommodate strange directional posting
like N in one direction and E in the other, as you appear to describe on
the Tulsa - Muskogee Turnpike.  This is easy on fully divided highways like
the Turnpike, as each directional "way" has its own role, even if both
directions are in a single relation as you've coded for your area.

I was excited to hear about N one way and E the other, as I've argued that
we need to handle this on single carriageway, bi-directional ways, using
(say) role=north;east.  In this case north would be posted as OSM forward,
and east as OSM backwards.  If the Muskogee Turnpike actually were a single
carriageway it would probably be better to code the ways "role=east;north"
with OSM forward running from Tulsa to Muskogee and to the south beyond,
because this is the increasing milepoint direction (according to
Wikipedia).  Martijn has shown how routes' ways can fairly quickly be
reversed and made consistent in terms of OSM forward, and I've done some
too (e.g., ID 21).  This can simplify directional role posting on long
single carriageway roads.

Of course the M-TWP is not a single carriageway, so OSM forward actually
runs in both directions, one on each carriageway, and the posting is simply
"role=east" or "role=north."  But single carriageway "semi-motorways" and
toll roads do exist, e.g., between Nara and Kyoto in Japan, or though the
Japan Alps near Shirakawago, or around Interlaken in Switzerland, or
through the Mont Blanc Tunnel between France and Italy. I've been lucky
enough to drive each of these in the past three months in the course of my
work, while thinking hard about OSM data structures.

With this in mind I have coded three OK relations, one modified from yours
for M-TWP northern section, one for the "free TWP" section posted as OK 165
(also modified from your work?)  and a new one for M-TWP southern section
(where no relation seemed to exist).  I've set them up with increasing
milepoint "ways" first, and reducing milepoint travel second.  You will
find the directional roles as I think they are actually posted on the
ground.  JOSM confirms that the ways are now in sequence in the three
relations, using its little wiggly line in the relation analyzer.  There is
one break only in each relation, where we switch from one carriageway to
the other.

After a little legitimate research on Google's Streetview (not copying, but
simply studying, as all good students should), so I concluded that the
northern M-TWP section is not posted counter-intuitively, as I thought
you'd indicated, but simply changes direction part way along.  You may know
better, and should of course improve on what I've guessed.  My evidence is
that the M-TWP on-ramp to Tulsa is posted "West" (not "North") on westbound
E Harris Road. So I assume it switches at that point from N-S posting to
E-W posting.  On eastbound E Harris Road I see the :"free" TWP on-ramp
posted as "South". This direction switch is what we might have guessed from
the road's alignment.

But what say you?  Is the west/north posting truly inconsistent on M-TWP?

Peter

PS. TWP is the abbreviation used for Turnpike on some big green signs in
New Jersey.  The funny thing is that most English speakers don't include a
W in that word, but in New Jersey apparently they do.  I believe it should
be pronounced "Twurnpwike".

On Sat, Jan 11, 2014 at 1:36 PM, Paul Johnson <baloo at ursamundi.org> wrote:

> I'm curious how this proposal works with roads like the northern section
> of the Muskogee Turnpike, which officially runs "North" towards Tulsa, and
> "East" towards Muskogee, the road's two terminii.
>
>
> On Fri, Jan 10, 2014 at 4:39 PM, Martijn van Exel <martijnv at telenav.com>wrote:
>
>> On Thu, Nov 21, 2013 at 1:27 AM, Chris Lawrence <lordsutch at gmail.com>
>> wrote:
>> > For example: way X pointing east is marked in relation Y as "east"
>> > (presumably we could assume that "east" = forward and the opposite
>> cardinal
>> > direction "west" is backward). User reverses way X. Now the relation
>> role is
>> > potentially backward.  JOSM seems to understand at least north/south and
>> > east/west and offers to fix it (see
>> >
>> http://josm.openstreetmap.de/browser/josm/trunk/src/org/openstreetmap/josm/corrector/ReverseWayTagCorrector.java
>> );
>> > no idea if iD or Potlatch do.
>> >
>> > We'd also need to make the validation tools smarter to recognize lossage
>> > (for example, realizing that the route is unbroken only if the chain of
>> role
>> > tags once you account for the directions of the underlying ways is
>> > monotonic),
>>
>> Picking up on this old thread again. The status is now that iD
>> partially supports the cardinal directions when reversing a way (it
>> does not understand things like north:unsigned, not sure if that is
>> easy to fix)
>> JOSM understands 'north' as well as 'north:unsigned' (and the other
>> cardinal directions of course) when flipping a way and offers to
>> correctly fix the member role.
>>
>> Relation sorting does not seem to take the member role into account in
>> JOSM, so that bit is not affected (or am I overlooking something?)
>>
>> The relation graph column in the relation editor does not recognize
>> cardinal directions in the same way it recognizes forward / backward
>> (with the dotted line display).
>>
>> The main thing I haven't looked into yet is the validation checks. Who
>> knows which validation checks are run on relations in JOSM and/or iD
>> to ensure 'unbroken-ness' and perhaps other things?
>> --
>> Martijn van Exel
>> OSM data specialist
>> Telenav
>> http://www.osm.org/user/mvexel
>> http://wiki.openstreetmap.org/wiki/User:Mvexel
>> http://hdyc.neis-one.org/?mvexel
>>
>> _______________________________________________
>> Talk-us mailing list
>> Talk-us at openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-us
>>
>
>
> _______________________________________________
> Talk-us mailing list
> Talk-us at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-us
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/talk-us/attachments/20140112/db42fe11/attachment-0001.html>