[OSM-ja] Feature Proposal - RFC - Proposed Japan tagging/Places

[gyotoku810]

gyotoku810です。

あまり苦言は呈したくなかったのですが、やはり建設的な対話ではなく論点先取 
や循環論法等々多くの詭弁を含んでいるように感じます。またこちらが既に回答 
した点に対して新たな反論がなく反対し続けたり、提案内容の直接的な改善につ 
ながらない過度な更新要求など、言いがかりや時間稼ぎとも見受けられる発言が 
目立ちます。

さて、

> 提案者様におかれましては、今回の回答をいいださまが示されたメリットととも 
> に Proposal ページに反映して頂ますよう要望いたします。

>> 「○○△丁目」にまとめることには、当該地名よりも、丁目なしの単独町名との整合性においての利点が大きいです。例えば「○○」と「○○一丁目」が併存する場合に、丁目を分割してしまうと前者の丁目なし町名の存在を明示できません。分割しなければ、「○○」と「○○一丁目」をそれぞれ配置することで適切にその位置を示すことができます。一方で、大字-小字式の場合に大字の下は複数の小字に分かれているが一部分で小字が存在しないという場合もあり、これは丁目なし町名とは異なり階層構造をなしています。「町名式」の地域で丁目を分割しないことで、「大字-小字式」のそのような場合を区別することができます。

については現在提案に記述されていないメリットのため提案理由に追記します。 
いいださんの意見については直接の提案理由というよりは補足的な意見とみえる 
ので、必要であればご本人より会話ページに記入していただくのが筋かなと思い 
ます。

> ２．のスプレッドシートに件は、単純にドラフトレベルからの更新漏れだと思っ 
> ていたのですが、ご説明のような意図があったということを理解いたしました。
> それでしたら、そのことを明示する必要があるということは提案者様でもご理解 
> できると思います。
> スプレッドシートに関しましてもご回答いただいた内容を提案ページに反映して 
> いただきますよう要望いたします。

街区符号・住居番号・番地について方針が定まっていない旨、またスプレッド 
シートはそれらを含まないものに差し替える旨を追記します。

> なお、ご回答の内容と『プレッドシートは差し替えることになります』では矛盾 
> しています。読み手に混乱を与えないよう適切な更新を要望いたします。

理解しかねます。どこが矛盾しているのか、混乱を与えているのか、他の方から 
でも良いので説明を願います。

> ３．の"Key:addr"については、前回の「Affect pages」についての提案の際に 
> 『「JA:住所」と「JA:Key:addr」は「Affect pages」から削除しない』と明言さ 
> れておられましたが、肝心の内容については記述しないと断言しておられまし 
> た。この辺りのご提案者様の説明には論理的に整合性がとれておらず、読み手を 
> 著しく混乱させております。

理解しかねます。『肝心の内容については記述しないと断言』とは何のことです 
か？　どこの論理的な整合性がとれていないのか、混乱をさせているのか、他の 
方からでも良いので説明を願います。

> 今一度、"Key:addr"についての考えを整理した上でAffected pagesの記載を見直 
> すなり、"Key:addr"の記述を追加するなりしたほうが良いと思います。（私はこ 
> の提案の内容と、いいださま、提案者様からの"Key:addr"についての今回の回答 
> とを鑑みるに「JA:住所」と「JA:Key:addr」の更新は必要ないとおもうのですが 
> ね）

quarterとneighbourhoodの日本における説明が変わりますので両ページとも編集 
が必要になることが明らかです。そもそも日本特有の記述が分散していることで 
混乱を招く恐れがあるため、その編集ついでにJapan taggingにそれらを集約さ 
せる、と書いてあります。


> １．"Affected pages"のリストが提案内容と異なる
> ２．変更する必要のない箇所（スプレッドシート）まで変更するように誤解を与 
> える。 
> ３．提案者が「○○」と「△丁目」は階層構造になっているということを理解して 
> いない。
> ４．この提案のプロセスが明示されていない。（「承認後に再度議論します。」 
> という変則的なプロセスを経るようですが、プロセスが明示されていません。）

全て反論済みです。1, 2については当メールで述べた通りです。3については 
『階層構造になっている』ことについて合理的な説明をしなければ有効な意見に 
はなりません。4について、本提案は通常の提案プロセスのガイドラインに則り 
ます。『承認後に再度議論します。』←そんなプロセスは経ません。前のメール 
で既に説明しましたがそれはこの提案より後の話です。そんなに私は間違ったこ 
とを言っていますか？

蛇足：あえて分割寄りの意見を申し上げますと、私は「○○」と「○○△丁目」でな 
ら階層構造（に近いもの）を成すと考えても悪くないとは思います。しかし 
「○○」と「△丁目」ではないと思います。

> 建設的に議論が進むように、「公開オンライン説明会」を開催していただけない 
> でしょうか、議題は １〜４＋α で、３は私が説明します。
> 日時はHappyHourの時間帯が良いと思います。

いきなり日時の話までしている辺り、自分の一方的に有利な場に引きずり込もう 
としているんでしょうけど（少なくとも私は主観的にそう考えます）、本提案は 
ご存知の通り複雑で文章をよく読み込んでやっと意見の理解および正確な批評に 
つながるものです。リアルタイムの対話をしたところで建設的な議論になるとは 
あまり思いません。また現在のhayashiさんの意見状況を鑑みるに、よりクロー 
ズドな場で直接対話することには危険を感じます。自らの反対意見を周知したけ 
れば勝手に説明会を開いていただいて構いません。

OSMの健全な発展のために、今一度建設的な議論を心がけたいものです。

gyotoku810

On 2022/05/25 23:47, hayashi wrote:
> hayashiです。
> 
> 提案者さま、いいださまご回答有り難うございます。
> 
> 提案者様におかれましては、今回の回答をいいださまが示されたメリットととも 
> に Proposal ページに反映して頂ますよう要望いたします。
> 
> なお、提案ページにおいては、「以前当MLでたくさん議論した通り」などの記載 
> ではなく、過去にどのような議論があったのかをまとめて記載すべきです。（云 
> うまでもないことですが、Proposalは議論に参加した人だけのものではないです 
> ので）
> 
> ２．のスプレッドシートに件は、単純にドラフトレベルからの更新漏れだと思っ 
> ていたのですが、ご説明のような意図があったということを理解いたしました。
> それでしたら、そのことを明示する必要があるということは提案者様でもご理解 
> できると思います。
> スプレッドシートに関しましてもご回答いただいた内容を提案ページに反映して 
> いただきますよう要望いたします。
> なお、ご回答の内容と『プレッドシートは差し替えることになります』では矛盾 
> しています。読み手に混乱を与えないよう適切な更新を要望いたします。
> 
> ３．の"Key:addr"については、前回の「Affect pages」についての提案の際に 
> 『「JA:住所」と「JA:Key:addr」は「Affect pages」から削除しない』と明言さ 
> れておられましたが、肝心の内容については記述しないと断言しておられまし 
> た。この辺りのご提案者様の説明には論理的に整合性がとれておらず、読み手を 
> 著しく混乱させております。
> 今一度、"Key:addr"についての考えを整理した上でAffected pagesの記載を見直 
> すなり、"Key:addr"の記述を追加するなりしたほうが良いと思います。（私はこ 
> の提案の内容と、いいださま、提案者様からの"Key:addr"についての今回の回答 
> とを鑑みるに「JA:住所」と「JA:Key:addr」の更新は必要ないとおもうのですが 
> ね）
> 
> 
> さて、幾度か質疑を重ねたのですが、
> 
> １．"Affected pages"のリストが提案内容と異なる
> 
> ２．変更する必要のない箇所（スプレッドシート）まで変更するように誤解を与 
> える。
> 
> ３．提案者が「○○」と「△丁目」は階層構造になっているということを理解して 
> いない。
> 
> ４．この提案のプロセスが明示されていない。（「承認後に再度議論します。」 
> という変則的なプロセスを経るようですが、プロセスが明示されていません。）
> 
> 「３」以外はどれも否決の理由になるわけですが、私としてはこんなことで否決 
> にしたくはありません。是非とも是正して本質的な議論を行えるレベルにしてほ 
> しいのですが、どうにも話が噛み合わないようです。
> 
> 建設的に議論が進むように、「公開オンライン説明会」を開催していただけない 
> でしょうか、議題は １〜４＋α で、３は私が説明します。
> 日時はHappyHourの時間帯が良いと思います。
> 
> オンラインミーティングの環境を準備できな場合は、私がホストになってもかも 
> いません。
> 
> OSMの健全な発展のために、ご検討のほどよろしくお願いいたします。
> 
> 
> On 2022/05/24 16:48, gyotoku810 wrote:
>> gyotoku810です。
>>
>>> → 「地方自治法上の告示」では分割されていないのかも知れませんが、現実 
>>> は 明 らかに「○○」と「△丁目」は階層構造になっています。「○○」と「△丁 
>>> 目」 を分割 する現行定義のほうが、名目よりも現実の地物を客観的にマッ 
>>> ピング するという OSMの基本方針とも合致していると考えます。にもかかわ 
>>> らず「地 方自治法上の 告示」に合わせるということはそれなりの利点があ 
>>> るというこ とだと思います。 「○○△丁目」にまとめることによるOSM的なメ 
>>> リットは何で しょうか？
>>
>> 少なくとも『明らかに』は言い過ぎですね。分割するほうが客観的であること 
>> の 理由はありますか？　現実の地物に忠実にマッピングするという点では分 
>> 割しな いほうが法的にも実運用的にも矛盾がありません。「○○」と「△丁目」 
>> が階層構 造をなしているような感覚は、「○○」は複数の「○○△丁目」の総称で 
>> あるとして 十分説明が付きます。このあたりは以前当MLでたくさん議論した 
>> 通りで、説明を 繰り返すことになりそうです。
>>
>> 「○○△丁目」にまとめることには、当該地名よりも、丁目なしの単独町名との 
>> 整 合性においての利点が大きいです。例えば「○○」と「○○一丁目」が併存す 
>> る場合 に、丁目を分割してしまうと前者の丁目なし町名の存在を明示できま 
>> せん。分割 しなければ、「○○」と「○○一丁目」をそれぞれ配置することで適 
>> 切にその位置を 示すことができます。一方で、大字-小字式の場合に大字の下 
>> は複数の小字に分 かれているが一部分で小字が存在しないという場合もあ 
>> り、これは丁目なし町名 とは異なり階層構造をなしています。「町名式」の 
>> 地域で丁目を分割しないこと で、「大字-小字式」のそのような場合を区別す 
>> ることができます。
>>
>>> ■ 『何らその地域固有の名称を表さないname=△丁目を持つneighbourhoodが全 
>>> 国 に大量に生じることになりかねません。』と記載されていますが、
>>>
>>> → 地物が多ければPOIの数も多くなるのは当然のことですから『大量に生じる 
>>> こ と』自体は何ら問題でないとおもいます。OSMとして問題と考えた理由も 
>>> し くは 具体的な事例を提示していただけますか？
>>
>> 問題なのはそちらではなく......『何らその地域固有の名称を表さない』のほ 
>> う です。固有名詞としての「△丁目」が存在するわけではありませんので、や 
>> はり 地名データとして分割すべきではないということです。
>>
>> ～～～～～～～～～～～～～～～～～～～～～～～～～～
>> 蛇足
>> 明らかに「○○」という地域が存在するのだから、「○○」をマッピングしたいと 
>> い う意見はよく分かります。例えば郵便番号は複数の丁目を束ねた町名ごと 
>> に割り 当てられているため、「○○」はboundary=postal_codeで表すことがで 
>> きます。た だし、複数の丁目の総称に過ぎないためplace=*のノードや 
>> admin_level=*でマッ ピングするべきではないと考えます。
>> ～～～～～～～～～～～～～～～～～～～～～～～～～～
>>
>>> 2-1. これは、現行の「OSMの地名・行政単位・郵便住所の対応」を「地名の 
>>> タ グ 付け例」に差し替えると言うことでしょうか？それとも、現行の「OSM 
>>> の地 名・ 行政単位・郵便住所の対応」に追加するのかどちらでしょうか？
>>> 仮に、追加ということでしたら、Proposal段階なので追加された完成形を提 
>>> 示 し ていただきたいです。
>>
>> 現行のスプレッドシートはquarter/neighbourhoodだけに留まらず、それ以下 
>> の 街区符号・住居番号・番地までに言及してしまっています。これらは町字 
>> とは完 全に切り離して考えることが可能で、例示としても地名と番地の両方 
>> を含むこと になり、議論や理解を難しくしています。
>>
>> 2022年2月6日に当MLにて「住所のaddr:*タグ」という件名で街区符号・住居番 
>> 号・番地に関するお伺いを立てましたが反応がなく、未だに明快な方針が定 
>> まっ ていないと判断しました。
>>
>> 本提案ではまず町字について整理するため、新しいスプレッドシートには街区 
>> 符 号・住居番号・番地その他提案に関係ない項目を含めていません。またス 
>> プレッ ドシートは差し替えることになります。
>>
>> 街区符号・住居番号・番地についてはきちんと方針を整えてから別のスプレッ 
>> ド シートで例示しなおすべきだと考えます。
>>
>>> 2-2. 現行では54件の例が挙がっていますが「地名のタグ付け例」は40件しか 
>>> あ りません。データを選別した理由は何でしょうか？
>>
>> 既存からの選別ではなく、地名タグ付けの考え方をよく表すよう一から選定し 
>> た ものです。冗長な例や番地等の例示を省いたこともデータ件数の減少の理 
>> 由と思 われますが比較対象ではありません。
>>
>>>> 2-3. 現行では (level2)nation から始まっていますが,提案では 
>>>> (level2)nation,region,(level3)state が削除されています。
>>>> 削除した理由は何でしょうか？
>>>> - (level2)nationが削除されたため グローバルとの接続がわかりづらいです。
>>
>> 提案に記載していないplaceタグ（nation,region,state等？）は現行から変更 
>> し ないということです。提案に記載の行を現行の表の当該行へ差し替えて読 
>> んでく ださい。
>>
>>> 3. "Key:addr"についてはどのように考えておられるでしょうか？
>>
>> addr:quarterにplace=quarter、addr:neighbourhoodにplace=neighbourhoodの 
>> 表 記法が対応します。番地以下は先程述べた通りの状況です。
>>
>> gyotoku810
> 
> _______________________________________________
> Talk-ja mailing list
> Talk-ja ＠ openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ja