Proposal:Multilinestring
(Redirected from Proposed features/Multilinestring)
Jump to navigation
Jump to search
| Multilinestring | |
|---|---|
| Proposal status: | Abandoned (inactive) |
| Proposed by: | Sletuffe |
| Tagging: | type=multilinestring |
| Applies to: |  , 
|
| Definition: | The multilinestring relation is used to represent one or multiple line strings made of even more ways compatible and as define by the Open Geospatial Consortium. |
| Statistics: |
|
| Draft started: | 2012-01-24 |
Relations of type multilinestring are used to represent one on the ground feature made of one or multiple line strings made of even more ways compatible and as define by the Open Geospatial Consortium.
Tags
| Key | Value | Explanation |
|---|---|---|
| type | multilinestring | Tells applications that this relation is for the same entity made of one or more line strings |
| whatever | whatever | Any name, highway, boundary, etc. that you see fit, this is only a geometry construction relation, do what you want with it |
Members
| Way or Node | Role | Recurrence? | Explanation |
|---|---|---|---|
|
|
zero or more | Ways making up the complete line string or making up lots of line strings | |
|
|
zero or more | Other type=multilinestring relations in a pyramidal construction. |
Usage
The intended use of multilinestrings is this:
- Tags describing the multilinestring (e.g., one boundary between two countries, one long river, ...) should go on the relation. The member ways should be left untagged, unless they describe something in their own right. For example, a boundary following a road only on a part, the road would be tagged with the highway tag, but could still be used as members for the boundary.
- If you have one or more way(s) member of the line string and it does not describe something in its own right, you may also put these tags on the type=multilinestring relation and leave the way(s) untagged.
- The direction of the ways does not matter.
- The order of the relation members should not matter (but properly sorted member lists can help human editors to verify completeness, therefore it is recommanded).
- All members of a multilinestring relation can always be used to build multilinestrings in compliance with the OGC Simple Feature standard (http://www.opengeospatial.org/standards/sfs). (Basically, since invalid multilinestrings made of ways doesn't exists in the OGC standard, it just means that nodes are not welcome in such relations.)
If you want other roles for other ways having some "relation" to the first relation then No, use another relation type, this is the whole point of this relation type, beeing simple and compliant with the OGC standards.
However, another relation could be created that can include this one.
How not to use it
Do not use it to group loose ways Relations/Relations_are_not_Categories (like all path in a forest) Example : if the name is not the same for all those ways, then you'd better not use this relation
see also (and why I didn't join those)
- Relations/Proposed/Collected_Ways This one was good, but it turns to be out of control with more role and more members added, it now goes to other goals
- Relation:route This one is very good for what it was made for, but not as simple as I want it to be for simpler cases (and not generic enough as the name suggest)
- Relations/Proposed/Collected_Ways_Simple This was my first proposal but conflicts with the previous, I prefere to start over, but ideas are taken from there