Plateauの方が新しいものだけをインポートして、それ以外はタブの未入力部分だけをインポートする

[yuuhayashi]

Takeshi.Sです。

素朴な質問ですが、建物オブジェクトにはタイムスタンプ的な作成日記録はないのでしょうか？

無くても履歴を追跡すればわかると思いますが、それと比較してPlateauの方が新しいものだけをインポートして、それ以外はタブの未入力部分だけをインポートするというのはスクリプトで出来ないのでしょうか？

---

Talk-ja mailing list 2022-04-05 t_sannoji01@yahoo.co.jp

[yuuhayashi]

はとちゃん＠小江戸らぐです。

すべての入力データは履歴（タイムスタンプ）があります。
ただ航空写真や標準地図をソースとして入力した場合、入力した履歴が新しく
ても、ソースが古ければ古いものとして扱う場合もります。そのあたりが
えいやとやるには難しいさせているのかと推察しています。

---

hatori@hatochan.dyndns.org 2022-04-06

[yuuhayashi]

hayashiです。

<はとちゃん＠小江戸らぐ>さんからの回答の通りです。すべてのオブジェクトには編集日時が記録されていますがあくまでも編集した日付であって、編集されたオブジェクトが編集時点に存在していたかどうかはわかりません。
編集時に何をソースとしたかはいちおう"変更履歴"に記述することになっていますがあまりあてにはできませんし、記載されていたとしてもそのソースの撮影日付まで特定することは難しいです。

現時点での方針

結局のところ、既存データとPlateauデータのどちらが新しいかというよりは、「''現実の現在の状況とPlateauデータとに相違がないかどうかを編集者が判断する''」ものという思想をベースにして、このスクリプトを作成しています。

Plateauデータが現状と相違ないならば入力しますし、現状と相違しているようならば入力をしない。という判定操作を編集者が容易にできるようにするのがこのスクリプトの目的です。
（既存データが現状と相違するかどうかはPlateauデータとは関係がないことなので考慮する必要はないはずです。）

「建て替え」への対応

「日付を比較する」目的はPlateauデータが作成された後に、建物が変更される可能性があるというとだと思います。

• A: 建物の用途が変わる（例：小学校が廃校になって校舎が博物館になった）
• B: 建物が取り壊された。
• C: 建物が取り壊されて、建て替えられた。
• D: 新たな建物ができた。
• E: 増築された。（形状変更）

というようなケースがかんがえられます。

そして、A～Eのそれぞれのケースについて、OSM上でその変更が反映された場合と、反映されていない場合の二つの状態がありえます。
さらにいえば、既存データが現実の建物の変更前を示しているのか変更後を示しているのかは編集日時を見ても判別がつけられないという問題があります。

ライフサイクルキーが付いている建物

上級編集者はこの問題を考慮して、オブジェクトの取り壊しや建て替えに際してLifecycleキーを明示している場合があります。

• A: 建物が放棄された（廃校された校舎） --> disused:building=* or abandoned:building=*
• B: 建物が取り壊された --> demolished:building=*
• C: 建物が取り壊されて、建て替えられた。　--> NODE:demolished:building=* + AREA:building=*

本スクリプトでは現在のところ、demolished:building=* キーがあるオブジェクトと重複するデータは*.mrg.osmには変換しないことにしています。 "Issue#60"

"end_date" キーがついている建物の扱い

ライフサイクルとセットで使われることが多いのですが、共用の終了日を示す end_date キーというものがあります。下記のように使われます。

• A: 建物が放棄された（廃校された校舎） --> end_date=2022-01-01
• B: 建物が取り壊された --> demolished:building=*, end_date=2022-01-01
• C: 建物が取り壊されて、建て替えられた。　--> NODE:demolished:building=*, end_date=2022-01-01 + AREA:building=*

ただし、下記のパターンでは end_date は使われません。

• A: 建物の用途が変わる（例：小学校が廃校になって校舎が博物館になった）
• C: 建物が取り壊されて、建て替えられた。
• D: 新たな建物ができた。
• E: 増築された。（形状変更）

本スクリプトでは現在のところ、end_date=* キーがあるオブジェクトと重複するデータは*.mrg.osmには変換しないことにしています。 "Issue#60"

"start_date" キーがついている建物の扱い

end_date キーに類似するキーに start_date があります。下記のように使われます。

• C: 建物が取り壊されて、建て替えられた。　--> NODE:demolished:building=* + AREA:building=*, start_date=2022-01-01
• D: 新たな建物ができた。 --> AREA: building=*, start_date=2022-01-01

これについては "Issue#74" で対応することにします。

実際の建物状況とマッピング状況との関係

lifecycle-timing.txt

• 「撤去」状態を示すタグ付け方法には複数の方式があり、全てをサポートするのは現実的ではない。
• 実際には現実の全てのイベントがマッピングされているわけではない。
• 建物の建替えには、例示したように一つのオブジェクトを継続する場合と、新旧のオブジェクトを分ける場合のふたとおりあり、後者の場合が多い。
• 実際にはOSM編集がその時点の現状を表しているという保証はなく、４〜５年前の衛星写真を基に編集する場合が多い。

その他のアイディア募集

上記の様に、Plateauデータの判別に利用できるロジックがございましたら提案いただけると助かります。

できれば、提案の際には提案のロジックが正しく動作できることが検証可能なマトリックス表などを提示していただけると、スムーズに実装できるとおもいます。

[yuuhayashi]

'start_date'の値

'start_date'から値を読み取るのが意外と難しい。
新しく建てられた地物を発見すると'start_date'を入れたくなるのだが、いろいろな入力形式があって値を読み取るのは意外と難しい。'start_date=値' から Date を得るライブラリみたいなものはないのだろうか？
https://wiki.openstreetmap.org/wiki/Key:start_date

編集日時と'key:start_date'との関係

一見、オブジェクトの編集日時と'start_date'には関係がないように見えるが、実は密接に関係している。
'start_date=値'は、必ず編集時点よりも「過去の日時」になる。
この法則を利用して、'start_date=値'がある建物については「直近の編集日時」がその対象建物の存在が確認された最新日時とすることができます。

　既存建物の確認日時 ＝ 最終編集日時
　PLATEAUの確認日時 ＝ PLATEAUの調査日（別途指定）

既存 vs PLATEAU	対応
PLATEAUが新しい場合
既存のほうが新しい場合

[nyampire]

すべての市町村にあるわけではないのですが、gmlのなかにある、uro:surveyYearを利用するのはどうでしょうか。

伊那市のデータだと、こんなかんじに入っています。

<uro:surveyYear>2018</uro:surveyYear>

[yuuhayashi]

nyampireさんからの情報を活用させていただきます。

1. GML内のタグがあるものはこの値を利用する。

<uro:surveyYear>2018</uro:surveyYear>

２． <uro:surveyYear> が無い場合は、
conversion.json 内に設定された値（ "surveyYear": 2018 ）を読み取る。

３． conversion.jsonの surveyYear が設定されていない場合は一律で"2016" とする。

という感じでPLATEAU側のソースDATEを決定しようと思います。

[yuuhayashi]

現物 : PLATEAU : OSM のパターン検証

下記の図において、「今日現在」、「OSMオブジェクトの最終更新日」、「PLATEAUのソース調査年」をそれぞれを変数として想定し、考えられるそれぞれのパターンについての考察を行ってみます。

(1) 「今日現在＝450」(建物Aが実在する)、 「OSMオブジェクトの最終更新日＝400」(建物Aが存在する)、 「PLATEAUの調査日＝400」(建物Aが存在する) ケース。

OSMオブジェクトの状態	有効なオブジェクト	備考
(ア).OSM(建物A:工事中)	PLATEAU
(イ).OSM(建物A)	PLATEAU
(ウ)〜(ケ)	PLATEAU	(ウ)〜(ケ) は存在しない

(２) 「今日現在＝800」(建物Bが実在する)、 「OSMオブジェクトの最終更新日＝750」(建物Bが存在する)、 「PLATEAUの調査日＝400」(建物Aが存在する) ケース。

OSMオブジェクトの状態	有効なオブジェクト	備考
(ア).OSM(建物A:工事中)	OSM	どちらも古い
(イ).OSM(建物A)	OSM	どちらも古い
(ウ).OSM(建物A:撤去済)	OSM	PLATEAUが古い
(エ).OSM(建物A:削除)	ー	PLATEAUは古く間違っている
(オ)〜(ケ)	OSM	PLATEAUは古く間違っている

(3) 「今日現在＝1100」(建物Bが撤去済み)、 「OSMオブジェクトの最終更新日＝400」(建物Aが存在する)、 「PLATEAUの調査日＝750」(建物Bが存在する) ケース。

OSMオブジェクトの状態	有効なオブジェクト	備考
(ア).OSM(建物A:工事中)	PLATEAU	OSMが古い、でもPLATEAUも正しくない
(イ).OSM(建物A)	PLATEAU	OSMが古い、でもPLATEAUも正しくない
(ウ).OSM(建物A:撤去済)	PLATEAU	でもOSMが正しい
(エ).OSM(建物A:削除)	PLATEAU	PLATEAUは古く間違っている
(オ)〜(ケ)	PLATEAU	(オ)〜(ケ) は存在しない

• 上の３つのパターンは代表的なものだけで、実際には検証しなければならないパターンの組合せは無数に存在する。
• ここから単純な法則を見つけ出すことができない。
• 実際には'''OSMのソース基の調査日付とマッピング編集日との間には４〜５年のタイムラグ'''が生じており、このことがこの検証を更にややこしくしている。

[yuuhayashi]

結局、PLATEAUと現物とを比較するしか無いのでは？

過去２週間、この問題に本格的に取り組んできましたが得心できるロジックを見出すことができずにいます。

やはり、「既存データ」vs「PLATEAU」ではなく、「PLATEAUは現物と合致しているか？」という基準で判断すべきではないかと思います。
現物と合致しているなら、既存データを書き換えるし、合致していないなら書き換えない。（既存が間違っているかどうかはPLATEAUインポートのタスク外とする）というのが、普段の衛星写真を使ったマッピング方法と同じ考え方になるので自然な流れになると考えます。

プログラムではなく、マッパーが判断すべきでは？

ここまで煮詰まった原因は『既存データ優先という思想』が足を引っ張っている。ということに思い至りました。

v1.4.6現在のプログラムでは、OSM既存データがPLATEAUよりも新しい疑いがあるものについてはすべて、PLATEAUからの変換を行いません。
この仕様は一見、既存データ優先の安全サイドに倒しているように見えますが、実は「マッパーが判断可能な機会をプログラムが勝手に奪っている」ということになっています。
今回の検証でも下記の理由により、POIオブジェクトの有効性をプログラムで判別することは非常に困難だということを実感しました。

• start_date end_date の曖昧性。
• 編集日時と情報源の不一致
• ライフサイクルタグの多様性
  プログラムでは判定しづらいので、ちょっとでも怪しいものは強制的に「既存優先」と判断し、PLATEAU変換を放棄しています。

何でもかんでも「既存優先」にするのではなく、プログラムで断定できないものはマッパーに判断してもらう というスタンスこそがOSMらしい仕様じゃないかと思います。

マッパー主権の仕様に変更する

そこで、現在の『インポートデータをプログラムで完成させてアップロードするだけ』、という現在の設計方針を改め、『マッパーが判断しやすい＆操作しやすいデータをプログラムで用意してあげる』という考え方にシフトしようと思っています。

第１弾：　「MLIT_PLATEAU:fixmeの拡充」

MLIT_PLATEAU:fixme 種別	意味	操作
delete 削除されます	PLATEAUデータに置き換えられてあぶれた既存建物	既存建物を削除しないで残し立てればこのオブジェクトを削除する
update 更新されます	PLATEAUデータに書き換えられたオブジェクト	書き換えたくなければこのオブジェクトを削除する
update 撤去建物と重複しています	ライフサイクル建物と重複する start_date,end_date建物と重複する	書き換えたくなければこのオブジェクトを削除する
orignal	既存オブジェクトの形状変更を行わずにタグだけマージしたもの updateとorignal はセットで存在する。	updateとorignal のどちらか採用する方を残してもう片方は削除する

※ ただし、マッパーが行う作業が煩雑化するというデメリットがあります。このあたりの兼ね合いが難しいです。ぜひ皆様のご意見を伺いたいです。

[yuuhayashi]

更新日時を利用する合理的なロジックが提案されないようなのでこのIssueはボツとします。