IIDAさん、ikiyaさん コメントありがとうございます。 タグ付けの件は了解しました。 大字は=quarter のままとしておきます。
その他、 (1) ref="大字町丁目コード" を入れています。 これは、都道府県名と市区町村名へ逆引き参照可能なようにするためです。 (Addressタグも考えたのですがADDRESSの書式でめんどくさいことになりそうだったのでREFにしました) (2) すべてのノードに<tag k="fixme" v="既存のノードが存在しないかチェックしてください"/> を入れています。 「インポートし放ち」にならないよう、インポート後に既存ノードの有無を確認してFIXMEタグを削除する作業をするようにしました。 この際にOSM的に良い位置にずらす作業も入るかと思います。 (3) source= "ISJ 2012" 位置参照情報の利用規約にデータの年式を入れるように書いてあったような気がしたので・・・ *位置参照情報の利用規約をみたところOSMの手動インポートでも問題ないようにおもいます。 そもそもGPXを使ったトレース方法も、手動インポートと何が違うのか? って感じてますから... テストインポート テストインポートもなしにいきなりバルクインポートはないとおもいます。 まずはコントロール可能な綾瀬市でテストインポートをやってみて問題点をあらいだしてみました。 特に綾瀬はすでに基盤地図情報から地名をトレース済みですので既存データとの競合状況を見ることができます。 その結果、quarterが表示されなくなることがわかったのですがそれはいいとして、 既存データとの調整も必要になります。 中島さんが指摘されたように算用数字表記などもあるので機械的に重複を検出するのは難しいかと思います。 また、一概に既存データのほうが位置参照情報よりも精度が高いとは言えないとおもいます。 大字・町丁目レベル位置参照情報 はそれほど数が多くないので手動インポート方式のほうがバルクインポートよりも手っ取り早いように思います。 その他に気づいた点として、基盤地図情報と位置参照情報ではノードの位置が違う(ずれているのではなく明らかに別の位置に置かれている)。 綾瀬市を見たところでは、位置的には基盤地図情報のほうが的確な位置が指定されているように見受けられます。 福島県など他の地域ではどうでしょうか? もし、基盤地図情報の位置のほうが位置参照情報よりも的確ならば、 下記のようなトレース方法が可能です。 ・基盤地図情報からGPXを作成 ・位置参照情報からOSMファイルを作成 ・JOSMにGPXとOSMをロードして、OSMノードをGPXの位置へ移動させる(既存データのチェックも行う) ノードを移動させる位置ですが、 (1) 地元などで地名の適切な位置がわかる場合には適切な位置に配置する。 (2) 既存ノードが存在する場合にはそのノード位置に配置する。 (3) GPX(基盤地図情報)があればGPXの位置に配置する。 (4) 位置を判断する基準が何もなければ位置はずらさない。 とするのは如何でしょう? それと、既存データが存在していた時の処理基準も決めておく必要があるでしょう。 例えば ・place=hamlet なら 位置参照情報で置き換えるのかどうか ・漢数字と数字との違いの場合は書き換えるのかどうか などです。 各市町村ごとに作業を行うとすると、だいたい1市町村に60〜150ぐらいの地名数になります。 JOSMでの手作業が、1時間で100地名ぐらい処理できますので、市町村単位に処理を分担するとちょうどいいかんじです。 ながながと書いちゃったのでまとまりがつかなくなっちゃいました。このへんにしておきます。 早々 2014年4月13日 20:33 Satoshi IIDA <nyamp...@gmail.com>: > > いいだです。 > >> 林さん > >> 「大字・町丁目レベル位置参照情報」からのデータは place=neighbourhood に統一するというのはどうでしょう? >> (理由) >>・そもそも、「大字」と「字」を区別することに意味があるのか? > > 階層わけの時に、僕も悩んでいたことです。 > https://lists.openstreetmap.org/pipermail/talk-ja/2013-August/007558.html > > 位置参照情報でいえば、主に "大字・字・丁目区分コード" が "2" になっている項目です。 > こうした、地籍からの住所表記を引き継いでいる地域の場合、 > 大字と小字を繋げた表記がとても長くなります。 > > 例えば、"大槻町字小山田西"のようなかんじです。 > なので、これは分割しないと、階層構造的にもレンダリング的にもよろしくないのではないか、と思って、分ける形にしました。 > > でもって、住居表示でいえば、大字に対応する階層は "町名" になります。 > 小字に対応する階層が、XX丁目、などになります。 > > なので、分けたほうがよいのでは、と考えた次第です。 > > ただ、どこまでが大字で、どこまでが小字なのか、わかりづらく、 > 入力がしづらいというのも事実としてあり、そこもずっと意見が欲しかった場所です。 > > 住居表示がされている区域と、そうでない地域で階層定義を分けるのも、ひとつの手ではあります。 > (例えば、大字は quarterにする、住居表示されている、XX町XX丁目、はまとめてneighbourhoodに入れる) > 階層的には美しくありませんが、実用的ではあります。 > どうしても町名のみで表記したい場合、type=boundary でsubareaなどを使って階層付けることもできます。 > この場合、一丁目、二丁目、などの前に半角スペースを入れて、 > 例えば "XX町 四丁目"としておけば、機械的にも処理しやすくなる、かもしれません。 > > > その地域が住居表示を実施しているかどうかは、 > 同じく位置参照情報の "街区レベル位置参照情報" (もう一つのファイル)に、判定のフラグがあります。 > HTMLであれば、このページになります。 > http://nlftp.mlit.go.jp/isj/preparation.html > > > >> ・トレースの場合には name=* の他にも place=[neighbourhood | >> quarter] を切り替えなければならないので大変な労力を要するようになる。 > はい、それもあるので、インポートとして、機械的に分割する方策を進めたほうがよいのではないか、という提案をしていました。 > トレース作業も、それはそれで行えば、構造のチェックにもなると思いますし、 > インポート作業まで待てないかたも多いでしょうから、手段としてはあって良いと思っています。 > >> テストインポート > 過去のデータ変換の基準にそっていて、不要と思われるタグが多いように思われます。 > テストとはいえ、ちょっとよくないな、と思っています。 > (ご存知とは思いますが、インポートを進めるには、それなりに手続きが必要です) > > タグの変更、あるいはリバートが必要と思いますが、どうでしょうか? > > >> place=quarterがosm.org本家でレンダリングされない > place=neighbourhoodがレンダリングされるようになったのもここ半年くらいなので、 > 個人的にはちょっとずつ進んでいる思っていたりします。 > > place=neighbourhood のレンダリングが追加された時のPull Requestはこんなかんじですので、 > 提案はやってみてもよいのかもしれません。 > https://github.com/gravitystorm/openstreetmap-carto/pull/28 > > > > > > > 2014年4月13日 17:57 ikiya <insidekiwi...@yahoo.co.jp>: > >> Ikiyaです。 >> もう一点、トレースしたかった理由は大字(町名)をきりはなして、同一大字のセンターに大字名を手置きしたいという理由がありました。 >> インポートでも大字、字の切り離し、タグ分けは希望します。 >> 私の方はまだトレースは始めていませんので、意見まとまった時点で開始します。 >> >> _______________________________________________ >> Talk-ja mailing list >> Talk-ja@openstreetmap.org >> https://lists.openstreetmap.org/listinfo/talk-ja > > > > > -- > 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