JA:Proposed features/Tagging for complex junctions or traffic signals that are named
| 名前が付いた複雑な交差点や信号機にタグ付けする方法 | |
|---|---|
| Proposal status: | Canceled (inactive) |
| Proposed by: | sommerluk |
| Rendered as: | 名前をレンダリングする(場合によっては信号機のアイコンをつける) |
| Draft started: | 2014-08-23 |
| RFC start: | 2014-08-24 |
| Vote start: | 2014-09-28 |
| Vote end: | 2014-10-12 |
背景
いくつかの国では、現在地を把握するために、道路の名前ではなく、交差点の名前(韓国など)や、信号機の名前(日本など)を用いています。ほかの国では、大きな交差点(片側二車線道路など)に名前がついている場合があります(ポーランドなど)。道路の名前が付けられていることもありますが、あまり重要視されていません。
世界の多くの国においては、この機能はあまり役に立ちませんが、いくつかの国ではこの機能は非常に重要です。道路の名前よりも重要なのです！
期待されるレンダリング
交差点に名前がついている場合は(韓国やポーランド)、その名前が(水平に)レンダリングされることが期待されます。信号機に名前がついている場合は(日本)、名前と信号機アイコンがレンダリングされることが期待されます。
名前は交差点の中央にレンダリングされることが期待されます。
名前は交差点にひとつだけレンダリングされることが期待されます。
本機能の現状
シンプルな交差点
name=*とjunction=yes または highway=traffic_signalsが付けられているノードに対して、この機能は実装されるべきです(junction=yes と highway=traffic_signalsが両方ついている場合は、交差点の名前であると解釈されます)。詳細については“Named spots instead of street names” を参照ください。このタグ付けは日本や韓国などの国では広く用いられています。openstreetmap.org (openstreetmap-carto)ではこの機能はレンダリングされています。現状では、シンプルな交差点については明確なルールがあります。二つの道が交差するノードにタグ付けします。このルールはコミュニティに受け入れられており、ソフトウェア上でもうまく機能しています(レンダリングソフトやナビゲーションソフトなど)。シンプルな交差点については、変更の必要はありません。
複雑な交差点
交差点は非常に複雑な場合があります。車線数が多く、中央分離帯があり、信号機が多く設置されているようなケースです。右に表示されている例について考えてみましょう。現時点では、このような交差点をタグ付けする明確なルールは存在しません。交差点に設置された信号機は、全体として"信号システム"(すべての信号機が一体となって働いています)とでも呼ぶものです。日本では、この信号システムに名前がついています。しかし、現時点ではこのような交差点や信号システムに対する適切なタグ付け方法は定義されていません。
提案
シンプルな交差点については、現状で問題ありません。現在の運用を続けます。
複雑な交差点や信号システムに関するタグ付けルールが必要です。交差点の名前と信号システムの名前については、類似の方法が適用できると考えられます。最終的には同じ機能となるでしょう。また、この機能は世界の中では一部の国でしか使われないため、ソフトウェア開発者があまり力を入れないかもしれません。これも両者を同じ機能にしたほうが良い理由です。OSMマッパーが使いやすい機能にしたほうがよいでしょう。さらに、レンダリングソフトやナビゲーションソフトが活用できるデータにすることも必要です。既存のシンプルな交差点等と互換性をとることも必要です。
| 名前付き交差点 (韓国など) | 名前付き信号機 (日本など) | |
|---|---|---|
| タグ付け方法 | 韓国で複雑な交差点をマッピングするには、交差点の周りにエリア(閉じたウェイ)を描きます。このエリアにjunction=junction_area (と name=*)をタグ付けします。 | 日本で複雑な信号システムをマッピングするには、信号システムのエリアの周りにエリア(閉じたウェイ)を描きます。このエリアにhighway=traffic_signals_area (と name=*)をタグ付けします。 |
| エリアの描画方法 | エリアは車道や歩道とノードを共有するようにします。それにより、ナビゲーションソフトは、どの車道や歩道が対象であるのか判断することができます。どの道路がエリアに属し、どの道路がエリアに属していないのか明確にするためには、(エリアと道路が)共有するノードは次のようにしなければなりません：
| |
| レイヤー | ほとんどの場合ではレイヤーを設定する必要はないでしょう。レアケースでは、交差点の下にトンネルが通っており、交差点とはつながっていないケースなどが考えられます。このケースでは、トンネルを通る道路は交差点エリアとノードを共有してはいけません。このような場合ではlayer=*をつけるのが便利でしょう(エリアや関連する道路につける)。 | |
これは簡単で直感的に理解しやすいアプローチです。iDやJOSMで簡単にタグ付けすることができます。ナビゲーションソフトが、交差点を通過する道路を判断することも容易にできます。
このタグ付け方法は、名前がついてない交差点に関しても適用可能です。ナビゲーションソフトが、「ふたつめの交差点で右に曲がってください」とか「四つ目の信号を左に曲がってください」と指示した場合を考えてみるとわかりやすいと思います。
特殊ケース：同じ場所に複数の交差点名や信号機名を付ける方法。現実にそのような場所があるというよりは、理論的な可能性です。このようなケースでは、複数のエリアを描き、交差点を囲むようにします。
理論的には、highway=traffic_signals_areaのタグ付け方法では、エリアは新しく描くことになりますが、個々の信号機は従来通りhighway=traffic_signalsをつけます。これらのノードはエリアの中に位置することになります(ほとんどの場合では、個々の信号機は信号システムと同じ名前を持つでしょうから、個々の信号機にname=* タグは不要です。個々の信号機が違う名前を持っている場合は、name=* をつけるのが良いでしょう)。We do not forbid this strictly because it makes sense to keep this door open for the future. ただし、現時点ではこのようなタグ付けは行わないことを推奨します。というのも、日本の地図においては、交差点ではアイコンをひとつだけレンダリングすることが期待されているのですが、現時点ではレンダリングソフトがアイコンの重複を取り除くのは難しいためです。そのため、日本においてはエリアのみを描くのが最適な方法でしょう。
投票
I approve this proposal. --Sommerluk| 14:45, 28 September 2014 (UTC)- I approve this proposal. Although I don't see a reason why this should only be used for named junctions. If - for any reason - one wants to group together all the elements of a junction, why not use an area with junction=junction_area without any additional tag? --Imagic (talk) 15:08, 28 September 2014 (UTC)
- I approve this proposal. A necessary solution to a problem of missing data in Asian maps. --Javbw (talk) 21:33, 28 September 2014 (UTC)
I oppose this proposal. for the named traffic signals. You will always find cases where drawing a simple area will not be possible or easy. A more generic solution would be to create a relation - e.g. type=traffic_signals - grouping the synchronized traffic signals and put the name there. Btw, a proposal already exists. --Pieren (talk) 09:48, 29 September 2014 (UTC)
- It will IMHO become difficult when you want to have named 'junctions' (not traffic signals) in a relation. How could routing/turn-to-turn navigation software use this data? Probably you would have to do something like tagging all “crossing” nodes in order to allow to a routing engine to process the data. And the relation is probably quite difficult to maintain. --Sommerluk| 18:26, 29 September 2014 (UTC)
- "You will always find cases where drawing a simple area will not be possible" - can you provide an example? Mateusz Konieczny (talk) 06:08, 11 October 2014 (UTC)
- I oppose this proposal. What's the point of having two different tags (junction=junction_area and highway=traffic_signals_area) to represent the same thing (a junction of some sort)? A more generalized tagging scheme that could cover all possible use cases, not just those in two Asian countries, would be much more beneficial to the OSM community. --Alester (talk) 17:11, 29 September 2014 (UTC)
- The point is that in one case you have a 'junction' name and in the other case you have a 'traffic signal' name. And we expect also a different rendering (junctions just with their name, while traffic signals have an icon).
- Concerning the usage outside of Asia I agree with you. While the proposal comes from an asian background, it is not restricted to Asia and will work also elsewhere. --Sommerluk| 18:26, 29 September 2014 (UTC)
- I approve this proposal. I think this would be helpful to prevent rendering junction names multiple times. Math1985 (talk) 12:54, 30 September 2014 (UTC)
- I approve this proposal. nyampire (talk) 02:26, 05 October 2014 (UTC)
- I obstain this proposal. I see the need and see the solution working in maps, though it might be important to improve the relationships with other features that are included in and just close by when moveing toward useing it in areas where the junction is over, under or inclosing other features (some junctions in the world are very large). Another issue could be how easy it is to use with software linking logicaly with just the connecting nodes on the "routing ways" (a term for the centre pathing line when the road parts are also described with areas too: in non area parts such as the examples given, read "routing ways" as the normal road lines). It would be good to intergrate this proposal with the other area-highway schemes as they could be used in conjuction.
- A solution could be done by a relationship to unite the joining nodes (on the routing ways), the new junction area given here (needed to help discribe the scope of the labeling with the junction name) and any defined highway areas (or relatable features (like islands and verges)). With such a relationship being added the machine comprehendability is greatly improved for a more automated or data-centric OSM use where the map isn't being rendered for humans to read.--Govanus (talk) 17:48, 6 October 2014 (UTC)
- I oppose this proposal. I really like this proposal, but I just noticed problem: "simple" and "complex" junctions will be tagged differently. Why not use "junction=yes" also for complex ones instead of new junction=junction_area? BTW, I just noticed that some named junctions exist in Poland (in fact, I was trying to mark one). Mateusz Konieczny (talk) 06:07, 11 October 2014 (UTC)
- The first draw was indeed using the same tag for simple and complex junctions. However, during the RFC time, it was discussed on the tagging mailing list that it would be better to have a separate tag (software compatibility, specially quality checkers…). Furthermore it gives the possibility to clearly define that the area in OSM corresponds to the area on the ground, with clear rules how to connect the area with the crossing ways – a concept that is a little different from the concept of the simple junctions.
- Is it even possible to have named junction marked as node (simple) inside complex one marked as an area? Mateusz Konieczny (talk) 20:25, 15 October 2014 (UTC)
- The first draw was indeed using the same tag for simple and complex junctions. However, during the RFC time, it was discussed on the tagging mailing list that it would be better to have a separate tag (software compatibility, specially quality checkers…). Furthermore it gives the possibility to clearly define that the area in OSM corresponds to the area on the ground, with clear rules how to connect the area with the crossing ways – a concept that is a little different from the concept of the simple junctions.
Voting was 5 times “yes” and 3 times “no”. I’ll revise the part for the traffic signals, considering the comments made here and at the mailing list. A new proposal will follow. Leaving this proposal here as “Canceled”. Sommerluk (talk) 20:25, 21 November 2014 (UTC)