[OSM-dev] Super-relations or not

Andy Allan gravitystorm at gmail.com
Fri Oct 29 10:45:05 BST 2010


On Fri, Oct 29, 2010 at 2:45 AM, Peter Budny <peterb at gatech.edu> wrote:

> That doesn't work; there are cases where it's ambiguous.  If you look at
> [1], US-278 runs along North Avenue (bottom) and Ponce de Leon Avenue
> (top), connected by Monroe Drive (left) and Piedmont Avenue (right).
>
> The problem is that North Ave and Ponce de Leon are both oneway=no,
> while Monroe and Piedmont are oneway=yes.  So unless you run a routing
> algorithm over the relation, you can't figure out just from the oneway
> tags that US-278 westbound doesn't include North Avenue (which you would
> otherwise assume from it being oneway=no).

Someone, somewhere, has messed this up good an proper. I can't find
the origins of this discussion to figure out where it's arisen from
though.

The situation you describe is easily dealt with using Route Relation
roles "forward" and "backward" as per cycle routes, or bus routes, or
every other route relation. See for example

http://www.openstreetmap.org/?lat=51.88888&lon=0.89395&zoom=17&layers=00B0FTF

It's clearly documented here:
http://wiki.openstreetmap.org/wiki/Relation:route#Members and rendered
on multiple maps. However, I see from elsewhere that people are making
route relations in the US and filling the memberships with "west" and
"south" and suchlike and then finding this causes problems. My advice
is to stick to the route relation member roles that work for every
other type of route, and if people reeeeaaaaalllly want to have
separate routes for I5 East and I5 West then feel free (something that
hasn't seemed necessary elsewhere) - but don't put the words "east" or
"west" in the ref, add an additional tag to the relation for "overall
direction" or something.

But please, stick with the forward/backward stuff for route relations
roles, it works well.

Cheers,
Andy



More information about the dev mailing list