RU:Proposed features/Multilinestring

From OpenStreetMap Wiki
Jump to: navigation, search
Доступные языки — Proposed features/Multilinestring
Afrikaans Alemannisch aragonés asturianu azərbaycanca Bahasa Indonesia Bahasa Melayu Bân-lâm-gú Basa Jawa Baso Minangkabau bosanski brezhoneg català čeština dansk Deutsch eesti English español Esperanto estremeñu euskara français Frysk Gaeilge Gàidhlig galego Hausa hrvatski Igbo interlingua Interlingue isiXhosa isiZulu íslenska italiano Kiswahili Kreyòl ayisyen kréyòl gwadloupéyen kurdî latviešu Lëtzebuergesch lietuvių magyar Malagasy Malti Nederlands Nedersaksies norsk norsk nynorsk occitan Oromoo oʻzbekcha/ўзбекча Plattdüütsch polski português română shqip slovenčina slovenščina Soomaaliga suomi svenska Tiếng Việt Türkçe Vahcuengh vèneto Wolof Yorùbá Zazaki српски / srpski беларуская български қазақша македонски монгол русский тоҷикӣ українська Ελληνικά Հայերեն ქართული नेपाली मराठी हिन्दी অসমীয়া বাংলা ਪੰਜਾਬੀ ગુજરાતી ଓଡ଼ିଆ தமிழ் తెలుగు ಕನ್ನಡ മലയാളം සිංහල ไทย မြန်မာဘာသာ ລາວ ភាសាខ្មែរ ⵜⴰⵎⴰⵣⵉⵖⵜ አማርኛ 한국어 日本語 中文(简体)‎ 吴语 粵語 中文(繁體)‎ ייִדיש עברית اردو العربية پښتو سنڌي فارسی ދިވެހިބަސް
Статус: Proposals with undefined or invalid status (inactive)
Предложена: Sletuffe
Схема тегирования: type=multilinestring
Используется на элементах: линия, отношение
Определение: 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.
В черновиках с: 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.


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


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.


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 shouldnot 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 ( (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