Show-ichi です。 多忙だったこともあって、すこし様子見していましたが、他の方の意見も出てきたので、意見表明しておきます。
まず、国土地理院調べで都県境の未定区間が14、都道府県内自治体の未定区間がざっと数えて66もあります。 これだけの数を例外と割りきって無視するのは無理筋で、きっちりとルール化する必要があることには賛成します。 原則論として、 ・現実に存在しないものは記述しない ・現状を記述できないルールは修正追補しなくてはいけない。 であり、境界の未定区間についても適応されるべきルールだと思います。 で、どのような手段で記述するにしろ、デフォルトで未定区間が確定区間と同様に扱われないようにする必要あると考えます。言い換えれば、未定区間の記述ルールを知らないレンダラーが正常な境界とは認識できないようにするべきです。 というわけで、現時点で未定区間を boundary=administrative を付したウェイで記述することには強く反対します。 最も理想的なのは、いいださんのいう対応案２ですが、現実的でないのには同意します。現状で適応できるのは湖面全体が未確定となっている場合だけでしょう（ただこの場合は重複ではなく除去が現実的）。 ところで、いいださんが、最も問題視しているのはboundary リレーションが閉じないことです。正確に言えば、不定区間を示すデータが無いので、閉じた範囲として解釈できないことです。 それを解決するには、当然ながら不定区間を示す何らかのデータを加えてやればいいわけで、そのために いいださんはウェイを引きたいと主張されている。 しかし、そのデータはウェイである必用があるのでしょうか？ リレーションはメンバとしてノード・ウェイ・リレーションのいずれも含めることができます。つまり不定区間をノードやリレーションで表せるならば、ウェイでなくてもリレーションシステムを根幹から修正する必要はありません。単にboundary リレーションの解釈やレンダリングを日本向けに拡張するだけでいけます（つまり日本をあつかわないなら対応する必要はない）。 では、不定区間を表すのに何が必要か。それには最低限未定区間の両端を表す２つのノードで十分です。 そしてこの２つが関連していることを示せば良い。つまりこの２つのノードをメンバとするリレーションを定義して それをboundary リレーションのメンバとし、日本の領域でboundary リレーションを範囲として扱いたいレンダラやパーサーだけが、それに対応（単純にウェイに置換するなど）すればいいのではないでしょうか。 未定区間を範囲の一部としてあつかうために、両端だけでは不十分なら、現在のリレーション仕様ではメンバは順序列ですから、両端のノードの間に参考点を追加すればいいでしょう。 これなら、日本の独自ルールというあつかいでも成り立つのではと考えます。 == Show-ichi 2013年10月10日 1:01 yuu hayashi <hayashi....@gmail.com>: > hayashiです。 > > 未確定の県境の件ですが、私は boundary=administrative > をウェイにつけて、確定された県境をまさに「境界線」として表現するのが自然ではないかと考えます。 > 未確定のところにわざわざ暫定的なWEYをいれる必要はないとおもいますが。 > > それと、未確定の県境の例としては、富士山の頂上付近が良い例だと思います。 > 国土地理院の地形図で富士山を見ていただけると、静岡県と山梨県の県境が５合目付近で途切れています。 > > 地理院さんの方式にならって、「県」をエリアでタグ付けするのではなく、素直に「県境」をウェイでタグ付けするのが簡単で問題も少ないように感じますが？ > > > 2013年10月9日 20:58 Satoshi IIDA <nyamp...@gmail.com>: >> >> >> いいだです。 >> >> この件、提起から一週間くらい経つのですけれど、特に意見ない感じでしょうか？ >> >> 特にご意見がないようであれば >> ひとまずの暫定回避案として、方法案1の、 >> 県境未定の部分に特定のタグを入れることで、 >> データとしてはエリアを閉じながら >> 描画させなくすることを可能にする、という方向性でゆきたいのですが、よいでしょうか。 >> >> >> > 1. レンダリングによる解決方法 >> > まずは国土数値情報のインポート用データなどを元にして、 >> > 暫定的な境界線のウェイをデータとして作成します。 >> > この状態で、該当のウェイ部分に何らかのタグ(例: "disputed=yes"など)を入れ、レンダリングから表示させなくすることが可能です。 >> >> 今週末くらいまでご意見をお待ちしてみたいと思っています。 >> 「意見あるけどまとめるのに時間かかるからちょっと待って」でもいただけると嬉しいです :) >> >> よろしくおねがいします。 >> >> >> >> >> >> 2013年10月2日 23:27 Satoshi IIDA <nyamp...@gmail.com>: >> >>> >>> いいだです。 >>> >>> admin_levelや住所についての内容がおおむね固まってきました。 >>> 次の一歩を進めたいと思います :^) >>> >>> 日本には、県の行政区境 (boundary=administrative)が位置未定の地域がいくつか存在しています。 >>> この部分のデータ記述方法について、どのようにしたらよいか悩んでいます。 >>> >>> 図がないとわかりづらいとおもうので、内容についてWikiのtalkページを作りました。 >>> http://wiki.openstreetmap.org/wiki/JA_talk:Tag:boundary%3Dadministrative >>> >>> ■ざっくりまとめ >>> ■現状の問題点 >>> 県の境が未定になっている部分について、 >>> 現在、一部のウェイが無いためにエリアを円周として閉じることができず、 >>> 正しくリレーションを形成することができない。 >>> >>> ■対応策案 >>> 1. レンダリングによる解決方法 >>> まずは国土数値情報のインポート用データなどを元にして、暫定的な境界線のウェイをデータとして作成します。 >>> この状態で、該当のウェイ部分に何らかのタグ(例: "disputed=yes"など)を入れ、レンダリングから表示させなくすることが可能です。 >>> >>> osm.jpレンダリングなどでの実現が可能です。 >>> 本家osm.orgでのレンダリングはあくまでサンプルであることを考慮ください。 >>> >>> 2. 係争地になっている部分に、それぞれの主体が主張するウェイを作成する >>> 英語版の議論ページにて、係争地になっている境界線の書き方として以下の議論があったようです。 >>> http://wiki.openstreetmap.org/wiki/Talk:Tag:boundary%3Dadministrative >>> >>> >>> 2つ以上の行政主体が存在し、それぞれが主張する領域ラインが明確である場合は、この方法が使えると思います。現在、利用可能なデータがないため、データを探してくる必要があります。 >>> >>> 3. ウェイの外周を閉じなくてもよいよう、リレーションの仕様を拡張する >>> 現状のままウェイを削除しておき、リレーションのouterメンバーを閉じないという選択肢の提案があります。 >>> OSMデータ構造の根幹に手を入れることになりますので、海外開発コミュニティとの連携が必要になります。 >>> >>> また、現状すぐに実現できるわけではありません。 >>> >>> データを利用するアプリケーション側としても、こういった「壊れたリレーション」の扱いには苦労しているようで、現実的な解法がどこからも出てきていないのが現状です。 >>> >>> ■いいだ個人の意見 >>> 現状を考えると、1の案が現実的ではないかと思っています。 >>> >>> >>> ■参考 >>> 『東京にも領土問題 千葉・埼玉との境界が未確定』日本経済新聞 電子版 >>> http://www.nikkei.com/news/print-article/?ng=DGXNASFK0500G_V00C13A9000000 >>> >>> >>> >>> >>> -- >>> Satoshi IIDA >>> mail: nyamp...@gmail.com >>> twitter: @nyampire >> >> >> >> >> -- >> Satoshi IIDA >> mail: nyamp...@gmail.com >> twitter: @nyampire >> >> _______________________________________________ >> Talk-ja mailing list >> Talk-ja@openstreetmap.org >> https://lists.openstreetmap.org/listinfo/talk-ja >> > > > _______________________________________________ > Talk-ja mailing list > Talk-ja@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-ja > _______________________________________________ Talk-ja mailing list Talk-ja@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ja
