Hi,
Peter Budny wrote:
1) The common way, up to now, for storing routes that alternate between
single- and dual-carriageway has been to leave the single-carriageway
parts without a role, or with the role "north/south". This makes the
order of the members of the relation meaningless, since you
can't traverse the ways end-to-end in the specified order.
There is no requirement for the order to have meaning; it is just a tool
the server offers you, and you can use it or not.
The way I view route relations, it is less about traversal and more
about simply stating that a certain way belongs to a certain route. The
route relation doesn't lose its usefulness if a little bit in the middle
is missing.
I would simply group all bits together in the route relation, including
the dual carriageway pieces, and not worry about roles etc. - this can
all be deducted from the oneway tags.
This could be solved by adding the single-carriageway sections twice
(once with "north" and once with "south")
Please no.
2) If the direction of a road (e.g. north/south) is indicated by roles,
I recommend not to do that.
If anyone has a compelling argument against super-relations, or for
single relations, I'd like to hear it. Supporting both seems really
pointless
No, supporting them both is quite probably the best way forward. You can
start with doing a simple relation, and when you find that there's
something more complex to it you can still use a super-relation.
I always preach that you should write your code such that wherever you
expect a way, you also accept a relation that groups a number of ways.
If that were done throughout, then a super-relation would just be a
normal relation with one or two sub-relations thrown in as required. No
need to go up the tree and demand that super-relations exclusively
contain relations etc.
Bye
Frederik
--
Frederik Ramm ## eMail [email protected] ## N49°00'09" E008°23'33"
_______________________________________________
dev mailing list
[email protected]
http://lists.openstreetmap.org/listinfo/dev
