Proposal:Collected Ways Simple

This article or section may contain out-of-date information:

This proposal has been replaced by Relation:multilinestring. It is basically the same, only the value or type=* changes to express its OGC compliance.

The predecessor of the proposal is Relations/Proposed/Collected_Ways

If you know about the current state of affairs, please help keep everyone informed by updating this information. (Discussion)

Relation:type=collection
Proposal status:	Obsoleted (inactive)
Proposed by:	Sletuffe
Tagging:	type=collection Data item
Applies to:	relation
Definition:	A Relation to represent all the ways making up a street with a common name, the ways of a complete waterway or railway and possibly others.
Statistics:
Draft started:	2010-09-30

This is a proposal for a set of tags and members making a Relation to represent all the ways making up a street with a common name, the ways of a complete waterway or railway and possibly others. I.E a group of ways forming together a bigger logical way.

This could be determined by looking at names of ways, especially if they are connected, but this is a more convenient mechanism. It might be used where a street is broken up into multiple ways by bridges, changes of status (residential, unclassified etc), and so on, or where a a street pattern is not contiguous - lots of branching or discontinuous sections.

Note that numbering of roads is placed under Routes. See there for reasoning.

The collecting of ways into streets also overlaps with linking of carriageways of a dual carriageway (divided highway).

Though we can't do it yet, it should eventually be possible to drop any common tags on each of the constituent ways and have them on the relation instead, with constituent ways having preference if they deviate from the relation (e.g. a relation with 10 ways, relation has highway=residential name=Dover St, but one of the 10 ways has highway=pedestrian).

Tags

Key	Value	Discussion
type	collection
any tag	any value	All tags on the relation (besides type) are automatically inherited to the members, but tags on the members override those on the relation. Thus, the relation could have highway=residential, but some of its members could be tagged as highway=living_street. They could also have different names, etc.

Members

Way or Relation	Role	Recurrence?	Discussion
	(blank)	one or more	all the related ways that constitute this street, river, railway, or whatever

• Members might also be other relations forming the bigger entity(e.g. dual carriageways).
• Other "related" ways such as tributary rivers, buildings in the street, or nodes related somehow are not welcome in this kind of relation, another one should be invented, this one is meant to be kept simple.

Similarity with the relation type=multipolygon

This proposal was constructed with the same goal in mind as of the multipolygon relation. It does not apply to only specific cases, it can apply to any linear feature which requires to be constucted by more than one way member. You can see it a bit like the GIS MULTILINESTRING primitiv just like the osm multipolygon relation is a bit like the MULTIPOLYON GIS primitive

Using Collected Ways wherever Ways can be used

Since we will often have the need to split ways into smaller parts and/or to group small parts into one, it is assumed that in the long run, a "collected way" relation may take the place of an ordinary way everywhere. This means that everywhere one would normally expect a way, there could be a "collected way" relation instead.

This applies recursively, i.e. we will very likely allow a "collected way" relation to be built from not only normal ways, but also other "collected way" relations. This is important especially with respect to the planned upper limit for the number of members in a relation; it will become impossible to combine *all* ways that make up a transnational motorway into one relation.

Clients (editors, rendereres) are encouraged to accept "collected way" relations in lieu of a plain way wherever possible.