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

2022年 5月 25日 (水) 14:47:11 UTC

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