Proposal:Group relation (multiobject)
| Multiobject | |
|---|---|
| Proposal status: | Abandoned (inactive) |
| Proposed by: | LM_1 |
| Tagging: | type=multiobject |
| Applies to: | 
|
| Definition: | Relation to group elements that share properties or should be reused as a one object in multiple relations.
Aims to relieve mappers from repetitive work and database from duplicate tagging of the same feature. In some cases allows level of precision and accuracy that is not possible otherwise. |
| Statistics: |
|
| Rendered as: | not rendered in itself, depends on members and parent relations |
| Draft started: | 2012-03-15 |
| RFC start: | 2012-03-22 |
Proposal
A new relation type is proposed to group elements that represent one real-world object or should be reused as a one object in multiple relations. This relation does not map any specific feature (and therefore brings no information per se), should only make life easier for mappers (less clicking) and support more consistent mapping (one feature only tagged once). As a positive side effect adds systematic information about what elements belong together. Theoretically saves database space, as tags are not duplicated where duplication is not necessary. Allows more precise mapping for really enthusiastic mappers.
Rationale
Currently streets (and other ways) are split in numerous parts and each has separately tagged name, surface, maxspeed, width, highway type. All these tags are thereby duplicated
In public transport (currently approved scheme) many road parts are supposed be added in separate relations for both ways (possibly for multiple times if more lines share the same route). In the same scheme, parts of stops should be added to: stop_area relation and to a relation for each direction of each line using this stop (that might be around ten or more for more frequented stops). This is too boring, tedious and error prone activity to be done by human mappers.
Some names apply to things that are represented by multiple OSM elements. One real world feature is represented as many OSM elements (which is wrong).
Renderers' authors would have easier time putting repetitive labels on things knowing what belongs together.
Tagging short summary - general rules
Tag on the elements what is unique to them. If any information is (not randomly/coincidentally) common for more than one element (split road/facilities...) add them all to multiobject relation and put any common information tags on this multiobject relation. If a group of elements should be part of multiple relations of other types, group them in multiobject relation and include this relation to the parent relation.
If the extra contextual information is not needed, copying of tags from multiobject relation to all members shall produce valid output. The same goes for multiobject relation being member of other relations - multiobject relation members should be treated as members of parent relation.
Tagging - detailed
This proposal covers similar concept to Relation:multilinestring, but is more general (can contain nodes, unconnected road segments). These two could coexist together.
All the members should be treated equally (no roles). Tags on the relation should be primarily interpreted as being valid for the whole relation. Therefore source=* on multiobject relation should primarily be interpreted as source of the tags on that very relation. Similarly start_date should be primarily understood as the time when tags on the relation started to be valid.[1] Any tags on the relation can be treated as if they were on the members as fallback. If tags on members and tags on this relation differ, tags on members should prevail. For cases where roles are needed or desirable other relation type should be used.
Each member may be part of other multiobject relations. One, some or all parent relations of an element may be members of common parent relation. [2] If a member is part of multiple multiobject relations, all tags from parent multiobject relation are valid, unless contradictory and incompatible (cannot be true at the same time). Service tags like source should be treated in the same manner (all valid at the same time.[3] Contradictory tags on multiple parent multiobject relations should be treated as non-existent. Multiobject relation as a member of any relation: any members of multiobject relation can be treated as if they were members of the relation themselves as a fallback. Otherwise they should be treated as a single object. Tags that are not valid for all members should not be used on the relation or the invalid elements should not be members of the relation. In case this happens, conflicting tag should be ignored for all members[4]
Multiobject relation can form a tree-like structure.[5] This creates a simple form of inheritance, but it is not intended to substitute default values. Everything mentioned above is still valid for this case.
Only elements that share their properties for a reason (not coincidentally) should be grouped.
This would usually mean elements that would be understood as one in real world, but had to be split for OSM's internal reasons (something is valid for only some members)
| Key | Value | Explanation |
|---|---|---|
| type | multiobject | Identifies multiobject relation |
| whatever | whatever | Whatever is valid for all members |
| note | whatever | Optional note why the multiobject is there (what do members have in common if that is not obvious from the members and other tags themselves. |
Applies to
Any OSM element (
, 
, ) can be member of multiobject relation, all have the same role.
Affects
Does not affect mappers who are not interested. Benefits those who are interested. All currently used mapping schemes remain valid. There are currently no instances of type=multiobject relations.
This proposed relation can obsolete some currently used relation types (mostly undocumented, rarely used ones[6] like type=collection or type=group). For some use cases can overlap with site relation (if the specific keys are not used). This proposal partially overlaps with the semi-proposed multilinestring, but is more general and covers more use cases. These two relation types can coexist, in this case multiobject relation would not connect adjacent ways together (would be done by multilinestring), but would still be used to group streets that are not strictly linear, but branch under the same name, rivers that form islands and fork to merge again, any other groups that should be treated as one element for naming, tagging or relation inclusion.
Most importantly this relation affects any future suggested single use relations, that do something very similar (group things together), but are limited to a very narrow use cases.
Data users would be affected if they did not process Multiobject relation, but implementation should not be very complicated. Editors would have to be updated for increased comfort of editing, but would work just fine as they are now. Can affect performance positively or negatively based on actual activity performed, this should be negligible in both ways.
For compatibility reasons old tags should not be immediately deleted from the members for at least some generous transition time. Backwards compatibility can in worst case scenario be achieved by simple pre-processing.[7]
Example use cases
Some use cases were suggested in Rationale section.
=Street
Example 1: All ways creating a street (common name) are members of a multiobject relation. Tags like name, references to the whole street, surface or width that is valid along the whole street are tagged on the relation.[8] Tags specific for only a part of the street should be on that part only.
Example 2:[9] Half of the street is rebuilt, mapper sees as important to precisely record this.
On the street group with name the start_date for the whole street is recorded (time when the street has been initially built).
One more multiobject relation is created; this becomes member of the street relation instead of the original way segments.
This relation contains the reconstructed segments.
It is tagged with the new surface, width, etc.
Meta-tags like source, note or start date are valid for this section.
As a result, one can tell: There is a street called "Long street" since 1789, since 1999 half of it has asphalt surface.
Example 3: There are traffic rules - limitation that are valid as a zone rather than on an individual place.
Pedestrian zones in town centres are one example. This is another one.
Trucks are not allowed to transit the city, but can transit any particular road if their target location is within the city.
This situation cannot be mapped in any satisfactory way today.
=Public transport
Streets used by multiple lines are grouped in one multiobject relation without any tags. This relation is member of individual route relations (and not members of the master route). Stops that are served by multiple lines can be members of this relation as well.[10]
Stop area[11]
It is suggested, that all features for one stop with the same name (all directions) are grouped in one relation. Also the stop features like stop_position and platform are supposed to be included in the route relation. Therefore, the individual stop features have to be included twice. The proposed multiobject relation would contain all the stop features in one direction. Stop area relation would contain only one multiobject relation per direction (stopping place within stop_area) and any features shared for all directions[12]
=Other
Barriers like fences or walls in urbanized areas form a network, because they are usually connected to other barriers. Currently it is not obvious what lines form one physical barrier. If all lines that form one physical barrier are members of one multiobject relation, this information is retained. It can be used in advanced 3D rendering to determine what should be rendered in the same style.
Comments
References
- ↑ See Examples section.
- ↑ This is an implementation hint more than recommended use scenario.
- ↑ Example: surface=paved and surface=unpaved cannot be valid at the same time and are contradictory, therefore should be ignored. Any surface=* on lower level or the element itself are still valid. On the other hand valid multiobject relation can be member of multiple route relations (as multiple roads can use the same physical road). Similarly
- ↑ Subject to discussion, this "rule" might partially conflict the principle that lower levels have precedence.
- ↑ Deep tree structures, while technically valid, are not encouraged, mainly because of Potlatch users' comfort. This can change over time.
- ↑ Judging from value of type key
- ↑ Using the fallbacks mentioned above - that is copying any tags to members and including any elements in parent relations. Transition away from multiobject relation can generally be automated, transition towards multiobject relation cannot be automated as additional information is required.
- ↑ For compatibility reasons, they can remain on the individual ways for a limited time.
- ↑ Subject to discussion, whether this should be valid. It is really detailed and maybe too complicated.
- ↑ This actually depends more on the public transport interpretation, since this requires certain order of members (stops first, route ways after
- ↑ Might be that I did not understand it correctly, if this is the case point this out, please.
- ↑ There can be more than two ""directions". Imagine a junction with public transport in both crossing directions - that is four at least. Stops with single name (one stop area) and many stop_positions are not uncommon. A bigger bus station can have 50 or 100 stop positions and each can serve maybe ten distinct lines. That is a lot of duplicity (and most importantly work and errors) if all the detail is mapped. Features shared for all directions and stop_positions would be toilets, buildings, restaurants, parking places etc. common for bigger stations. Regular public_transport stops (one pole and one shelter with a bench for each of two/four directions) would have none shared features between directions (routes).