Proposal talk:Collected Ways

Discussions (2007-2008)

Might it be better to use type=highway instead of street, for continuity? --Thomas Wood 19:21, 13 October 2007 (BST)

• I thought about that, but highway cuts across the intended use here, being both a collection of highways and a subset of a highway. But it's only a tag, I don't care much about the naming. David.earl 17:23, 18 October 2007 (BST)

• Why not use type=compound or type=collection? This way we wouldn't need distinct tags for highways, railways etc. --Schuetzm 13:14, 13 January 2008 (UTC)
  • I agree with a type as proposed by Schuetzm, I can't choose one or the other but we should urge the decision. with bridges, roundabout, forked ways etc... this relation is becomining necessary Yota 17:45, 30 April 2008 (UTC)

• do we need to tag each ways with the "global" name... or only put the name in the relation ? Yota 17:46, 30 April 2008 (UTC)

Must member ways connect to each other (with identical start/end-nodes, ignoring direction), so we get one continous path along the different ways? Must member ways have identical tags, i.e. "street"-members must be only of type "highway=*"? If so: who asserts these conditions to keep consistent data? JOSM lets me add arbitrary ways to a street-relation (non touching ways, even mixing in waterways and railways), which just doesn't make much sense to me and presumably neither to a render or routing program. --Bebbimapper 22.37, 13 May 2008 (UTC)

I like this approach, but I think that naming it "collection" or "compound" would be better, and the tags that would be added to the way (if it weren't splitted) would be added to the relation. --Ehabkost 18:36, 15 June 2008 (UTC)

Full ACK. --Rayx 08:10, 20 June 2008 (UTC)

This proposal seems to be an alternative to Relations/Proposed/Segmented Tag. I think this approach is more intuitive than the Segmented Tag proposal, but it is worse for existing software: if the renderer (or other software) doesn't handle the compound relation, it will miss all the general info about the street (name and highway type). If the renderer doesn't handle the Segmented Tag, it will miss only the tags associated with the segmented tag relation (e.g. bridge, tunnel). Missing info about bridge or tunnel wouldn't be a big problem, but missing street name or highway type would be worse. However, I think that this proposal would be better, and worth the effort to add support to renderers. --Ehabkost 18:36, 15 June 2008 (UTC)

Replying to my own question: maybe an alternative to avoid problem for existing renders would be copying the tags from the compound relation to each way, before sending it to the database (this could be done by editors that support this kind of relation). This way even renderers that don't know handle the relation would see the collection-wide tags properly. --Ehabkost 18:39, 15 June 2008 (UTC)

I think I have changed my mind regarding my comment above. Relations/Proposed/Segmented Tag seems to be a better way to handle the problem of splitting ways when the sections that need different tags (e.g. tunnels and bridges), or belong to different sets of relations (e.g. bus routes). The "collected ways" approach may be useful on other cases, but I was thinking about the bus routes and tunnels/bridges cases. --Ehabkost 19:32, 15 June 2008 (UTC)

Contrary to what you've mentioned, the segmented tag method is much worse for current software. Handling for the collected ways is completely covered by the editors, the renderers also have basic handling written for them (I've heard default osm2pgsql for mapnik now nicely handles it, but I have to see first).

Segmented tags on the other hand will be already a problem in the editors, which do not allow adding relations to other relations as members, as would be needed for bus routes for example. The editors will also need to handle these segmented relations in a special way, since the current ways will certainly create a big mess for any user seeing the data on a road which has many segmented ways. Also, rendering software can't handle this at all yet.

And IMHO, the collected ways approach is much more cleaner and user-friendly, and are an excellent use of what relations were made for in the first place: all streets belonging together in one way or another (same street name, same bus route) in a relation. The segmented tags on the other hand is an ugly work-around (again, IMHO). --Eimai 20:32, 15 June 2008 (UTC)

I also think that this is much more intuitive than segmented ways, but there is also a case that segmented ways cannot represent: ways that fork. So even if segmented ways were used, you would still need a way of compounding several ways. --Schuetzm 08:08, 18 June 2008 (UTC)

I think we would have to remove the “name”-tags of the member-ways, to avoid redundant data. And why can’t we leave the connecting of ways with the same name to the renderer? --Rayx 12:46, 17 June 2008 (UTC)

OK, I thought about it after reading Schuetzm’s comment above and I have to agree with him. So my second sentence becomes invalid. But I still think we would have to remove the name-tags of the member ways. --Rayx 06:47, 20 June 2008 (UTC)

Why don’t we try a more general approach?

To me, the idea of having different types (street/river/stream/railway) depending on the collected feature is unnecessary, as is the restriction to name=* as a possible tag. Why don’t we just define a relation with type=compound (or type=collection, as suggested on the front page) and specify that every tag we put on the relation applies to every member of the relation? --Tordanik 08:22, 19 August 2008 (UTC)

I took the liberty to change the proposal according to your suggestions. I also removed the option to have nodes as members. --Schuetzm 09:06, 19 August 2008 (UTC)

Sounds good and lends itself well to automatic parsing that already needs to have a fallback to tags on ways. --MarcusWolschon 11:05, 19 August 2008 (UTC)

My personal feeling is that we shouldn't move the base tags like highway=residential to relations. I think we need to define exactly what to push into collected way as well, since you could easily add almost all streets in a country into one highway=residential relation, or a maxspeed=50 relation, which is obviously not a good idea. --Eimai 11:33, 19 August 2008 (UTC)

I tend to disagree, it is helpful to move tags to the relation, as it avoids duplication, however the purpose of this proposal isn't to move all tags to relations like in your example, but to share common tags between a logical group of ways by storing them in the relation that groups them. What I think would be needed is improved editor support for relations, so that when a way is selected, the other members of the relation are highlighted, and the common tags are displayed in a way that clearly shows that they are attached to the relation but apply to the selected way. Also it would be advantageous to highlight where the way tag overrides a relation tag. I prefer "collection" to "compound," I think it's a clearer description. I feel this general proposal is far preferable to the segmented ways proposal, which is rather complicated for new contributors to grasp. Just my immediate thoughts on the subject, anyway.Daveemtb 13:54, 19 August 2008 (UTC)

I didn't say I don't like the concept, it's far more better than the segmented tag proposal IMHO. I'm just saying that we need to define what we're moving to the relations. Obviously names and refs are a good candidate for collected ways. But if my entire city has a speed limit of 30, do we add all its roads to a single maxpeed=30 relation? Perhaps if it's a "Zone 30", but do we then add other roads on the planet with maxspeed 30 to that relation? Or similarly do we add all highway=residential roads in the planet to a single highway=residential relation? It's these issues I'm wondering about. --Eimai 14:55, 19 August 2008 (UTC)

The way I understood it, we would be not be adding everything to a relation just because they have the same tag. The purpose of this relation is to regroup a way that has been chopped up because of bridges, different speedlimits, etc. The tags on the relation are there to avoid duplication on tags that are the same across the split ways (such as name=#) Alexrudd 22:52, 20 August 2008 (UTC)

I think it would be logical to create 1 (one) relation for a connected entity, like a "street" (common name, common ref). I think it should be possible to store *all* information in the relation, if neccessary. And it should be possible to have a collected way in a collected way (e.g. "some street" and "another street" part of a "ref=X 123". I don't think using this scheme for networks of ways or some single tags. It should support human sense for one entity and grouping ways to this entity (like splittet streets because of bridges, limits, ...) --Dspies 11:57, 15 November 2008 (UTC)

Pondering this I've realized that type=collection/compound/whatever as a generalization with a collection=street/waterway/railway or similar tag to make specifics cases if required a much better option. I came to this conclusion realizing if we inherit tags from the relation (which is a brilliant idea for name= at least) we either do it from all relations (and as soon as there's > 1 relation and you don't put a name= on the way which one do you use?) or we have a specific type of relation we inherit tags from, this being the 'collection' relation. This is much easier to do if it's only 1 type of relation. So use the generic option I suggest, and add a tag do describe the type of collection, say collect=. *sigh* Now I've said that I have to go cleanup all my type=street relations, --Beldin 00:52, 14 December 2008 (UTC)

Well, there's a certain beauty in type=collection being a truly generic way of inheriting tags. The sense of collecting street segments in a collection is IMHO undisputable and appears generally agreed upon. But there's more: IMHO it does make sense to collect a set of spatially related streets in a collection if e.g. they form a speed zone. IMHO it does make sense to collect the entire set of streets of a city in a collection if e.g. they form an environmental zone. IMHO it should be technically possible to combine all residential streets of the planet in a collection, simply because the mechanism should be general, even if this doesn' make sense. Being a programmer I take a collection as a general mechanism to inherit tags. That, and the possibility to override tags in members, is a great oportunity to simplify things. But it's not a must, i.e. nobody must put all residential streets of the planet into a single relation. There will always be practical limits like the number of members an editor may allow, but there shouldn't be structural limitations. Why limit members to ways? Why limit collections to streets/ways/rails? Just try and imagine what a type=collection could be used for if it just was a way to inherit tags. --Tesche 16:24, 06 Februar 2010 (UTC)

Physical vs. logical attributes

I'm pondering this as a question of separation of physical and logical attributes. Let me explain what I mean. A segment of street has certain "physical" attributes that relate to the actual driving or walking on the road, it's size, it's number of lanes, sidewalks, zebra crossings, traffic calming, oneway, maxspeed, access, footpath, cycleway, etc. These attributes are prone to change along the street. It also has a number of "logical" attributes that do not affect the actual street, like name, if it's a part of a bus route, etc. The physical attributes belong on the way(s) themselves. The logical attributes belong in a relation if the street is more than one way. What I want to say is that I approve of this proposal :) Norpan 13:52, 18 November 2008 (UTC)

Street-Relation and Karlsruhe Schema

There has been the suggestion to use a type=street relation to bind the housenumbers to their street. A relation like this:

Tags

Key	Value	Comment
type	street	A street relation
name	*	The name of the street

Members

Type	Role	Recurrence?	Comment
	street or member	One or more	All ways that are part of a street (as in with the same name)
	house, associated or related	Zero or more	All kind of houses that belong to the street (as in have the address of the street). A single house-node, typically a housenumber node. A housenumber interpolation line (kind of 'interpolated houses'). A building drawn as an area, typically with a housenumber attached.

Since both the street-relation and the currently used accociatedStreet relation (which binds housenumbers to streets) do pretty much the same, it would be sensible to use one relation to bind all elements of a street together. Otherwise we would have one street-relation that contains all the street segments and at least one accociatedStreet-relation that either contains one of the street segments or maybe the street-relation. --Driver2 23:06, 29 December 2008 (UTC)

Not sure on the member roles: wouldn't it be more consequent with the Karlsruhe scheme if a house or other POI would get a role "addr:street"?

Also, is a "street" role really necessary? It should be obvious that a highway belonging to the street relation is a street...

Note that I would also add everything of that street in the relation, not just houses like you mention, but also things like bus stops, shops, schools... (i.e. all POI's). --Eimai 14:06, 30 December 2008 (UTC)

Another reason why a "street" role wouldn't be a good idea is that it should be possible to have "left" or "right" roles for some streets, since there are many streets that have different names on both sides. --Eimai 16:37, 1 January 2009 (UTC)

Fine by me. There was just the concern that it could be harder to find errors if you leaven the role blank for some members, why other need to have one. If all types of members do need a role, you can easily identify those without one as erroneous. However there is nothing to prevent people from just adding wrong roles. A validator could be used to check if for example members with a 'house' role have a housenumber or interpolation tag attached. Though there could also be houses without a housenumber just yet, a warning might still be prudent (as the validator does with many other things that might or might not be an error).

A right/left-role might be useful for some streets, though a warning would have to be implemented in editors if one tries to turn the direction of the way around. --Driver2 17:35, 1 January 2009 (UTC)

It's like with route relations: normal members also don't have a role, but where the route varies in both directions they get forward and backward roles. --Eimai 18:15, 1 January 2009 (UTC)

Merging these relation types sounds like a good idea. Are you going to create a stand-alone proposal for this? --Tordanik 16:13, 2 January 2009 (UTC)

I think we should not use the rule house for addresses because a address can also be a tower, a place, etc. Better would be to use member for the segments of the street and associated for related items, like houses or postboxes. --Phobie 04:49, 7 January 2009 (UTC)

What about "role=addr:housenumber" then with the existing "role=house" documented as deprecated? --MarcusWolschon 11:24, 7 January 2009 (UTC)

That would conflict with addr:housename and those informations are already saved in the members of the relation. We only need to separate members and related items. Everything else can be read from the child items. --Phobie 09:31, 29 January 2009 (UTC)

I can find no wiki-page documenting type=street. Only relations with type=route and route=road. --MarcusWolschon 11:45, 15 April 2009 (UTC)

Update: I found it. As one of the many alternative named suggested for the collected_ways -proposal. --MarcusWolschon 11:49, 15 April 2009 (UTC)

See also: Relations/Proposed/Street. --Driver2 20:00, 15 April 2009 (UTC)

Roles

it would be useful to have a roll call of roles which people have used as (to the best of my knowledge) there is not a comparable automated listing as there is for keys and tags via e.g. OSMdoc. --Ceyockey 00:14, 29 November 2009 (UTC)

The following appear to be "core":

• member → a segment of street where collection=street
• street → a segment of street where collection<>street
• address → an addressed element in the collection

What others are in use?

• traffic_control → a traffic control element like a traffic light, stop sign, etc.
  • users: Ceyockey
• link_out → a highway-link leading from a street member to a street which is not a member of the collection
  • users: Ceyockey
• link_in → a highway-link leading from a street which is not a member of the collection to a street which is a member
  • users: Ceyockey

I've made this statistic by using data from Tagwatch (Europe). I only looked at those two relations and only at roles that have at least a thousand uses or so.

Role	total (in those two Relations)	street-Relation	associatedStreet-Relation
house	58315	2717	55598
address	2534	2534	-
addr:houselink	2573	1261	1312
street	9181	768	8413
none (only ways)	6345	4195	2150

"house" obviously has the advantage of being used by associatedStreet and the Karlsruhe Schema and "street" or using no role at all seems to be the standard for street segments. --Driver2 23:19, 29 November 2009 (UTC)

Problems to solve when inheriting tags from parent relations

This is based on the assumption that all tags except for type=* are propagated downwards through the relation hierarchy. There was a discussion that routes are not intended for inheritance, but possible exceptions are not reflected in the text of this proposal and following the concept through, these problems will arise with any constellation of relations using inheritance.

Consider the following scenario based on hiking route relations:

• hiking routes are expressed by route relations
• a way may belong to several routes, e.g. a relation describing the road and multiple hiking routes and bus routes
• a way also belongs to the compound relation for its road
• a relation should have an identifying name for handling it in the editors
• a hiking route may contain ways as well as useful nodes and landmarks along the way
• such nodes do not necessarily have a name
• the ways of a route relation often are footways, paths, tracks or unclassified roads that have no name

Then the following problems manifest and will have to be solved:

Problem 1: "Unintentional tagging"

• when all tags except for type=* are propagated, all ways and nodes in the route relation will also inherit the relation's name
• thus the name of the route e.g. "Anton-Leidinger-Weg" will be rendered in the map as the name of on every path, track, signpost, parking, fireplace, shelter etc. along the route that does not have a name of its own

But the renderer (which would have to be aware of the relation to propagate the tags, or would you do that in the API?) could decide not to render the name for every component of the collection (unless it is different from the name tag of the collection) but only put the name at "reasonable distances" from each other.

And how would a renderer decide which tags are intentional and which should be ignored? This might even be different for relations created by different users. --Nop 22:23, 5 March 2009 (UTC)

A renderer would assume ALL tags are intentional (if a collection element should have e.g. a different name, it would have its own name tag, preventing the inheritance of the collection name). The decision to render a tag would however not be based on the tag being intentional, but on the visible aspects of the rendered image, e.g. render the name of a street or river only at least XX meters from the last rendered name of the same (member of the same collection and having the same name) street, not in a bend, ...

I'm still thinking as to how to implement this in the ODRPaintVisitor of Travling Salesman. The street-name is to be rendered near the center of the ways. It must be in the visible portion of the way. But if the way is a curve or loop it must still be on the way and not the center of the bounding-box. ...difficult. Any ideas about the details? --MarcusWolschon 06:58, 5 March 2009 (UTC)

The problem here is not how to place the repetitions of the name. The problem ist that anything that does not have a name of its own will inherit the name of the relation. There is many items that are members of relations, that do not have a name and that should not show one: paths, tracks, signposts, parking, fireplaces, shelters. They all will be labelled with the name of the relation which is plain nonsense.

Problem 2: "Multiple Inheritance"

• if a way or node belongs to several relations, which will be frequently the case when there is a relation for each route and another one for continuous roads, only one of those relations can propagate a tag to the way/node.
• the first relation to be evaluated that as a certain tag will propagate it, all subsequent evalations will find a tag already in place and cannot propagate theirs
• the order of evaluation is completely undefined and may vary for every run of a renderer or other client software. it may even vary with each database call during the same run
• so the tags actually used/rendered will jump between the values of different relations at random

Actually, multiple inheritance is known to cause even more tricky problems, which is the reason why programming languages have been moving away from the concept again, but these two samples should be enough to worry about for a start. :-) --Nop 12:12, 17 January 2009 (UTC)

Bad idea, if you want inheritance then it should be based strictly on specific type=* values. If you map tags from relations down to ways for walking, cycling or bus routes, boundary relations, or basically any other relation type now in use, you'll just create problems. The rules of inheritance have to be strictly defined, and the kind you mention above where all tags are just inherited should only occur with a type value especially defined for that purpose.

And in that case multiple inheritance is very easy to solve: just define it as "undefined" :-), programs looking for wrong tagging could pick it up easily. --Eimai 12:36, 17 January 2009 (UTC)

I agre that this proposal should be opposed since multiple inheritance is a nightmare. And since multiple inheritance can be inhibited only with a type system, which we don't have, I oppose even simple inheritance in the context of OSM.

Moreover, so far every OSM object is self-consistent: even relations do not add anything to other objects, they are object per se which could safely be ignored. Consider a relation of type route: even if it has a name, that name is not the name of the way the route is composed of, rather it's the name of the relation itself. That means that if you want to know everything about a way, you don't need to look further than the way itself. With this proposal, every data lookup would become much more complex. --FedericoCozzi 18:38, 12 February 2009 (UTC)

I think we should be as general as possible with inheritance. Thus allowing to inherit every value other than type and we should also allow all types of members (points, ways, areas and relations)! I agree that inheritance can raise conflicts and therefore we should discuss if we are able to cope with them. Take the name and maximum speed of a street for example: There may be multiple relations defining different names and speeds. Using multiple names (at least for segments of the street if they collapse and spread again) makes perfect sense. Although assigning different speed limits on the same segment is wrong.--Augustus.kling 20:35, 20 February 2009 (UTC)

Just to make sure that you're fully aware of the problem: If there are two possible speed limits in multiple relations, it will not assign two values as you state. It will assign one of the two values at random. Which one is non-deterministic, it may be a different one for each run of a program and it may be even a different value for two neighboring tiles on a map. --Nop 00:30, 21 February 2009 (UTC)

Well, if a segment of way is in two different relations specifying different speed limits, then it either should not be in at least one of them or the segment should be split and the parts moved to the different relations. So either way there is an error in the data that can easily be detected and (manually) fixed.

Yes. But this sort of problem is very hard to detect and hard to fix. How would you do that? Remove one of the values? Then it will be missing on other ways where it was correct. Change the relation memebership - breaking the logic if it was a group. Restructure the relations - makes it even more complex and difficult to understand and may introduce other side effects. --Nop 22:27, 5 March 2009 (UTC)

The handling of this problem would have to be done by the programs using the tags and depend on what they are using the tag for. A renderer could e.g. decide to display the lowest speed limit that is inherited by a street. I definitely would not automatically change any data. Better use a program like Gary68's waychecker to find and publish problems and rely on human editors to correct them.

So how would you decide which of several names you want to display? What about the problem that if you apply such rules, every renderer may implement a different rule with a different result? If the developer is not aware that a conflict exists, the behaviour will still be random. And this may happen to any tag in many different logical contexts. Can you expect every renderer to anticipate every possible conflict and provide a solution? Fixing all of this manually will simply not work, with such an unrestricted complex network every change is likely to break something else. It even may not be possible to detect some of these problems statically with a tool if the inheritance is over multiple levels and the problems depends on the order of evaluation. --Nop 09:44, 8 April 2009 (UTC)

Relation is not a pack neither a category : an object is in a relation as somewhat, by default as member. The relation has a type : route, street... This semantic point of view, taking in account the role and the type, may help writing rules : e.g. a highway can be member (role="" or role="street") of ONE relation:type="street", but can be member of several relation:type="route". Other ways, areas... can take place in a relation:type=street with a role that is niether nothing nor street (e.g; :house). In that way the inheritance of the name is leaded by the semantic. This can be helpful for a relation:type="river" where we can put the waterways as member or role="river|axis|..." but also the riverbanks as area or whatever witch will not receive the name. I think there is a strong (maybe heavy) way to write a scheme (like a DTD) of what is allowed (or taken in account actually) by OSM. If such a scheme exists, is public, is served by OSM, the tools (editors, renderers) will use it. FrViPofm 15:16, 18 June 2009 (UTC)

Getting the tags of a way

If this proposal was supported by the editors, it would make the data more logical and could save a lot of disk space. Although I see a big problem about the proposal: It is not easy to implement for applications, because suddenly, it would be a complex issue to get all the tags of a way. You would have to check all relations that a way is a member of, and then check all parent relations of these relations. Especially for searching, this could take a lot of time. The effort of writing a small script/bot that does anything with ways would become much bigger. Because of this, I think that this proposal is only acceptable with special support in the API, so that the tags of these collection relations are automatically added to the ways (with some XML attribute indicating where the tag is coming from). Thus I see this proposal being realised in API 0.7 if at all. --Candid Dauth 19:32, 15 May 2009 (UTC)

If a kind of XSLT exists, if the API can serve the rule for an element, the bot or whatever can know where searching for informations about this element : a highway can inherit its name from a relation:type="street" but not from a relation:type="route" for a renderer like mapnik. But for a rending of a bus network, the XSLT will be different and the name will be a concatenation of the refs of the different relation:type="route". Not sure we need to report the tags on the members of the relation. Yes, maybe in the API v. 0.7... FrViPofm 15:28, 18 June 2009 (UTC)

arbitrary changes

I made arbitrary changes on the proposal page to bring this proposal forward. IMHO we should try to join Collected Ways, Street and Karlsruhe Schema! Please post destructive aversions below. --Phobie 12:08, 7 July 2009 (UTC)

Another way of doing it???

Would an alternative approach be to allow/expect certain information appearing on a node to implicitly affect the whole of the next segment of the way (using the way's direction).

So if I put bridge=yes on a node, it means the next segment, since bridge=yes on a node is meaningless.

Of course if someone changes the direction, the editor would ideally flag a warning, and even better, shift any such on-a-node-but-shouldn't-be information to the other end of the segment.

I think this would cover the common situation (way broken for bridge/tunnel), without the complexity of inheritance issues.--RichardMann 14:43, 9 July 2009 (UTC)

This will not work, because if you hide information that belongs to the way (what you call "next segment") in a node, this is not recognizable for somebody who has selected the way (and who might split the way and thereby make your segment smaller). Put properties of the way on the way, not on nodes. --Lulu-Ann 09:53, 12 July 2009 (UTC)

Aggregation Vs. Selection

There may be some uses of collected and segmented ways for which this comment does not apply. But toward a general scheme for tagging a parent relationship instead of the child geometric ways:

• Reading Relations/Relations_are_not_Categories, it seems that the style of OSM is to be a spatially aware relational database.
• Thus if I want all the parts of Heald Rd. in the town of Carlisle, I need to do a spatial query where the road name is "Heald Rd." and the boundary is the extent of Carlisle.

Changing to a relationship scheme (e.g. a way is part of heald road because it is a member of the relationship) changes the fundamental way that data is returned...the relationship is now explicitly modeled rather than implied and queried.

It seems that there are a few ways this could happen:

1. Relations with duplicate tag names (E.g. the relation and the way have tags). I think we can agree that such a scheme would be inefficient.
2. Relations have names, ways do not, inheritance at the client level. This would put a burden on all clients to understand inheritance of tags...discussion above shows lots of problems with this.
3. Relations have names, ways do not, API provides inheritance. No problem for clients but still problematic from a schema standpoint.

OSM is a heterogeneous project - different people are working on different aspects of the map with different goals, schema, etc. Anyone approaching the map has to be prepared to ignore "stuff I don't care about". In that context, automatically inheriting relation tags down to a way would potentially project the "stuff I don't care about" into a place where I do care. Inheritance at the API level would not know what tags need to be inherited. --Bsupnik 03:08, 20 July 2009 (UTC)

Link Roads

Primary streets in big cities are often dual carriageways, and aslo consist of many ways due to turn restrictions. Moreover, it would be useful to add to the same collection their link roads and u-turns. Relation:route solves this problem by specifying "link" role for members. I think it can be useful for primary streets as well. --Yuri Nazarov 16:11, 17 September 2009 (UTC)

General Use of Collected Items

Why should the collection be limited to way type items? In my case, I have to tag a hotels that contains three buildings, which have names and POI tags of their own. So I'd prefer to tag them collectively. A similar idea would be a a factory which have several buildings that do not share a campus.

Basstoelpel 17:50, 20 January 2010 (UTC)

I agree with you. This also applies to many kinds of natural objects. Some examples in Lower Austria:

• cliffs: Peilsteinwände, Leitermauern
• crags: Krainernadeln, Götzensteine
• peaks: Drei Berge, various names with -kögerln
• caves: Schwedenhöhlen, Nebellöcher

Even for a single cave, it would be desirable to tag the name and other attributes pertaining to the entire cave only once, not on each entrance.

Thus, I would like to see a relation type=collection (this fits best, I think) for any kind of objects (nodes, ways, areas, sub-relations, or mixed). Renderers need to:

• Render the name (if any). Renderers may choose to label the members individually (at high zoom levels) or altogether (at lower zoom levels). In the latter case, a renderer may either put the label in the (possibly weighted) center, or stretch it over the area within the smallest enclosing convex hull. The biggest challenge is how to choose the text style best matching the members. E.g. if peaks are labelled with orange text, a collection consisting of only peaks (and collections of them) should be labelled with orange text too.
• Handle "general information" keys like website=*, description=* etc. as if set on an area. Use the same positoning strategies as for the name.
• Inherit all other tags (landuse=*, natural=*, building=*, access=* etc.) to the members. See chapter "Problems to solve when inheriting tags from parent relations".

--Fkv 19:20, 19 December 2010 (UTC)

Aggregation Vs. Selection II

The authors of the following wiki page (effectively) suggest that you should only create a Relation if there is a physical gap in the road which the computer can't be expected to know about:

Relations/Relations_are_not_Categories

(They actually say the opposite, but none the less if you follow the concept and not the examples ... :-)

If two ways share a common end node, and share common tags, then it is simply a split-polyline and anything more is redundant clutter which the computer could otherwise figure out for itself. i.e. it is not necessary to make explicit spatial relations in a spatially aware database (e.g. PostGIS), because that is already taken care of automatically. It is only necessary to make logical relations.

The multipolygon case is a lot clearer, where the Relation exists to say that the inner polygon is a hole in the outer one, not an overlay. for example: for a lake tagged as natural=water, an island would be a hole in the water, but a marine reserve boundary would be an overlay.

Following the same idea for a road, I can see the relation being useful for when a road stops at one side of a river and starts again on the other side, and there is no bridge that connects them.

I'm not saying that using the Relation for split-but-connected roads is an error, I'm just saying it is (AFAICT) useless & unneeded clutter; and anything which harms the signal:noise ratio is counterproductive in the long run, especially things that clutter people's understanding of the architecture of the underlying data model (loose as it may be).

--Hamish 10:49, 18 April 2010 (UTC)

More generic as possible

I thing that this relation shouldn't have any specific thing !

than a relay simple way it to don something like this:

Tags

Key	Value	Comments
type	collection	required
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	Comments
	none	one or more	everything related to the way

The goal steel to apply the tags of the relation on all his members.

---

But it's can be too basics, it don't respond to all needs for Karlsruhe Schema than I purpose a non specifics extension:

Tags

Key	Value	Comments
type	collection	required
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.
on:category:any tag	any value	All this kind of tags on the relation (besides type) are automatically inherited to the members that have the Role category

Members

! Way or Relation	Role	Recurrence	Comments
	none	none or more	everything related to the way
	category	none or more	everything related to the way

I add on: before my new tag category to escape any problem with tags like mtb:scale.

I thing that the real advantage of this solution is to don't have any specific thing.

---

For Karlsruhe Schemawe cad do :

Tags

Key	Value	Comments
type	collection	required
on:road:highway	a valid value for highway
on:road:name	the street name
on:house:addr:street	the street name
...	...

Members

! Way or Relation	Role	Comments
	road	the road segment
	house	the house

This is an not so difficult to use the data for a programmer but is it for a standard mapper ?

CU Sarge 14:09, 29 September 2010 (BST)

The result of a total generic aproach is total confusion for the mapper. It already fails for the name tag: Is this realtion not allowed to have a descriptive name as all tags are inherited to all members? --Nop 20:28, 29 September 2010 (BST)

What I'd like would be not only to be generic but also more simple. Just like the type=multipolygon is doing great for any kind of surface object and only cares about geometries, I'd like type=collection to be the same thing for (multi-)linestrings. That proposition has been changed too much in order to become too complicate, the revision id I like is this one : Relations/Proposed/Collected Ways Simple sletuffe 20:52, 30 September 2010 (BST)

Using this (or better Collected_Ways_Simple) for buildings as well

There's currently no way to properly map building consisting of parts of different heights (as a single object with one address), and I think this relation is perfectly suitable for this task as well. Example:

<way id="1">
  <tag k="building:levels" v="1">
</way>
<way id="2">
  <tag k="building:levels" v="9">
</way>
<relation id="3">
  <tag k="type" v="collection">
  <tag k="building" v="yes">
  <member type="way" role="" id="1">
  <member type="way" role="" id="2">
</relation>

I've tried to invent a relation for this purpose specifically, but it turned out to be very similar to Relations/Proposed/Collected_Ways_Simple. To not duplicate functionality, I vote for Collected_Ways_Simple to be used (for buildings as well) --AMDmi3 15:05, 23 March 2011 (UTC)

2013: Future of collections

The collection relation is no longer used for the things that are described in the proposal:

• collecting street elements moved to relation:street and relation:associatedStreet and relation:address
• railways and roads are in relation:route
• streams and rivers are in relation:waterway
• linear features collections have a new relation relation:multilinestring--Werner2101 (talk) 08:09, 24 February 2013 (UTC)

Note that relation:multilinestring is not a "collection" as in categories it is meant to respect One feature, one OSM element sletuffe (talk) 10:52, 26 February 2013 (UTC)

The usage of collection currently is:

• networks: collections of hiking routes which can use Relations/Proposed/Network
• artwork collections
• Aerial Imagery collections
• any kind of other collections

that nobody likes. (see. Relations are not Categories)

What shall we do with the proposal an this relation type? For now am adding a warning. --Werner2101 (talk) 08:09, 24 February 2013 (UTC)

+1. I also added a link to Relations are not Categories. This proposal wasn't such a bad idea at the start, but wether it was it's name "collection" or people who missunderstood it, it seams to be used as a categorie relation. sletuffe (talk) 10:52, 26 February 2013 (UTC)