いいだです。 > 平成23年度のデータ はい、僕はこちらを使っていました。
> 画像解析でデータ作成 これ、できたらいいですね(*´ω｀*) (ただ、具体的にどうやって処理するのかぜんぜんわかってない。。) 利用する画像としては、Mapboxさんの衛星画像でも、 元絵作成くらいはできないことない気がしています。 (衛星画像は、JOSMの画像プリセットに入っています) ライセンスも問い合わせやすいですし、色調もくっきり。 欲を言えば、あと1レベル2レベルくらい拡大したいなぁ。 2013年8月16日 9:41 ikiya <insidekiwi...@yahoo.co.jp>: > ikiyaです。 > > ２点ほど情報提供？です。 > すでにご存知でしたらあしからず。 > > １点目は森林データの更新状況についてです。 > > 国土数値情報（JPGIS2.1(GML)準拠及びSHAPE形式データ）の森林データは > 現在平成18年度版と平成23年度版が公開されています。 > http://nlftp.mlit.go.jp/ksj/gml/datalist/KsjTmplt-A13.html > > 当初OSMへの森林データのインポートは平成18年度版だったかと思います。 > http://wiki.openstreetmap.org/wiki/Import/Catalogue/Japan_KSJ2_Import > > 以前、新しい平成23年度版の森林データに精度向上を期待して、 > 福島県と埼玉県のSHAPEデータ比較しましたが > 私には見た目ほとんど差が内容に見えました。 > 福島県のデータには少しですがポツポツと平成18年データからの変更箇所がありましが、 > 改善 されているところもあれば改悪？（かえって現況にあわなくなる修正）されている場所もあり > 平成23年度のデータにはしょんぼりした記憶があります。 > 他の県のデータがどうかは確認していません。 > > > ２点目は広域の森林を書く方法についてです。 > > 森林トレースに関してはBing画像が使えるのであれば > Bingを背景表示できるGIS系エディタで森林画像の森林色しきい値をねらって > 森林の輪郭線（境界線）強引に取得する方法もあると思います。 > （フォトショップなどで自動で輪郭を選択するような方法） > その際に使うBing画像のタイルは大縮尺ではなく小縮尺側 > （zoom14もしくはzoom15あたり）にで充分だと思います。 > > イメージとしてはこのくらいのBingタイル > http://tools.geofabrik.de/mc/?lon=133 > .95505&lat=34.93733&zoom=14&num=2&mt0=mapnik&mt1=bing-satellite<http://tools.geofabrik.de/mc/?lon=133.95505&lat=34.93733&zoom=14&num=2&mt0=mapnik&mt1=bing-satellite> > 小縮尺側のほうがしきい値は設定しやすい（色が均一化してる）かと考えます。 > > 国土数値情報の森林データよりは現況にあった森林の輪郭線が取れそうな気はしますが、 > こんなプランはどうですかという私の提案です。 > > 課題としては以下の２点かと思っています。 > ・利用するソフト選定とできるだけ容易な操作方法 > ・Bing画像の利用方法 > どうやって背景表示させるか。背景表示の利用方法はライセンス上問題ないか > > この分野のご専門、エキスパートの方々にご意見いただければよいかと思います。 > > > --- On *Thu, 2013/8/15, Satoshi IIDA <nyamp...@gmail.com>* wrote: > > > > いいだです。 > > KSJ2の森林データを再インポートするにあたって、Import MLでも話をしてみました。 > 付与するタグや、メッシュで分割した構造については問題ないのですが、そもそも論として > > 「KSJ2 森林データの位置精度が悪すぎるのではないか」 > > という指摘がありました。 > 例えば、現況とあまりにもずれていたり、水面の上にはみ出ていたり。。。という具合です。 > > 確かに、既にインポートされている森林データに関しても、 > 巨大リレーションの扱いが煩雑であるということにくわえ、道路や建物と被っていたりすることが頻繁にあります。 > (しかも「お国のデータ」という印象のもと、特に慣れないうちは、修正を躊躇ってしまうかたが多いのも確かです) > > しかしながら、西日本の森林は、なにがしかの形で復旧させる必要があると考えています。 > と、いうわけで、復旧方法として2つの選択肢がある気がしています。 > > 1. ゼロからトレースする > GeoRepublicさんが管理されているHOT Task Managerなどを使って担当地域を分割し、複数人でトレースを行います。 > 参照する情報として、主にBingや基盤地図情報を使います。 > > http://osmtm.pgrouting.org/ > > 2. .osm形式に変換したファイルを修正してからインポート > 元々のファイルを二次メッシュで分割し、さらに .osm形式に変換したファイルを、私が作成します。 > できあがったファイルをOSM wikiなどで配布し、複数人で修正を行いながらインポートを行います。 > (Yahoo/ALPSインポートと同じようなフローを想定しています) > > インポート作業となるため、各人でインポート用アカウントの作成が必要です。 > また、できれば1回のアップロード時に75000オブジェクトくらいのサイズ単位で > アップロードをしたほうがよい、という提案をもらっています。 > > なお、国土数値情報の利用約款として、成果物の二次利用・公開を妨げるものではない、という認識です。 > 特に二次配布を行うことについて、懸念がある場合はご指摘ください。 > (もちろん、参照しているファイルの情報などはWikiに記載します) > > http://nlftp.mlit.go.jp/ksj/other/yakkan.html > > （３） 国土情報およびそれを利用者が編集・加工して作成した成果物を他に転載、引用等する場合は、利用者は「国土数値情報（○○データ） > 国土交通省」「国土画像情報（カラー空中写真） > 国土交通省」のように出典を明記してください。また、国土数値情報の整備年、国土画像情報の撮影年・撮影場所、ファイル名、編集・加工した場合には編集・加工責任者等の情報についても、できる限り併記してください。 > > 個人的には1のほうが精度の高いデータができる気はするのですが、 > さすがに範囲が広大なので、ちょっとどうしたものかと思っています。 > > 2の場合も、もともとの精度がよくないことがあり、修正にはわりと手間がかかります(^^; > > ご意見いただけると嬉しいです。 > > > > > 2013年7月10日 22:15 Satoshi IIDA > <nyamp...@gmail.com<http://mc/compose?to=nyamp...@gmail.com> > >: > > > いいだです。 > > 二次メッシュで分割したデータ、拝見しました。 > Multipolygon Relationのouter, innerもバッチリです！ ステキです！ > (欲を言えば、二次メッシュ部分でウェイが重複してるウェイがあるのですが、 > 致命的ではありませんし、十分以上に利用可能なデータです) > > GRASSはぜんぜん触ったこと無いので > こちらでの再現がどうにもスタックしていますが、少しトライしてみます。 > > > > > > 2013年7月8日 21:16 Nobusuke Iwasaki > <wata...@gmail.com<http://mc/compose?to=wata...@gmail.com> > >: > > いわさきです。 > > > ただ、2つのポリゴンが重複している部分で、ウェイ自体も重複しているなど、 > > OSMデータとしては美しくないものになってしまいました(^^; > > あと多分、MultiPolygon Relationの outer, inner指定もちょっとおかしくなっている感じがします。 > > なるほどです。 > その辺ちゃんとやろうとすると，ディゾルブをかけたりとか，なんとか，そういう処理が必要になるかな？ > おっしゃるとおり，可能な限り07のデータをつかって，問題になったときに対処しましょう。 > > > > こちらも、交差処理自体は問題なく完了したのですが、 > > OSM的にはエラーが大量であまり美しいとは言えないデータにな > > っており、そのまま使うのはちょっと難しそうです(^^; > > 了解です。 > こちらの方は，GRASS GISで同じ処理したもの（島根）を，個別に送りますので，ちょっとそちらで確認していただけますでしょうか。 > よろしくお願いします。 > > > > 2013年7月8日 13:23 Satoshi IIDA > <nyamp...@gmail.com<http://mc/compose?to=nyamp...@gmail.com> > >: > > > > いいだです。 > > > > ありがとうございます！ > > > > で、いただいた手順で実際にやってみました。 > > > > ■複数Shapeファイルの結合 > >> 検証用ということ事で，よろしいでしょうか。 > > はい、検証用で使いました。 > > いただいた手順で、 > > Shapeファイル結合自体は無事うまくゆきました。 > > > > ただ、2つのポリゴンが重複している部分で、ウェイ自体も重複しているなど、 > > OSMデータとしては美しくないものになってしまいました(^^; > > あと多分、MultiPolygon Relationの outer, inner指定もちょっとおかしくなっている感じがします。 > > > > これらは妥当性検証をかければ潰してゆくことができるのですが、 > > 単純に手間がかかってミスする可能性が高くなるので、あまりやりたくないのが正直なところです。 > > 可能な限り、07のデータを使うようにしたいな、と思っています。 > > > > ■二次メッシュとの結合 > > こちらも、交差処理自体は問題なく完了したのですが、 > > OSM的にはエラーが大量であまり美しいとは言えないデータにな > > っており、 > > そのまま使うのはちょっと難しそうです(^^; > > > > 二次メッシュファイル自体を .osm化して、 > > JOSM側でやったらうまいことできないかな、とも思っているので、もう少し考えてみます。 > > > > 分割は必須ではないと思っているので、できたら今週末くらいには作業したいなー。 > > > > > > -- > > Satoshi IIDA > > mail: nyamp...@gmail.com <http://mc/compose?to=nyamp...@gmail.com> > > twitter: @nyampire > > > > _______________________________________________ > > Talk-ja mailing list > > Talk-ja@openstreetmap.org<http://mc/compose?to=Talk-ja@openstreetmap.org> > > http://lists.openstreetmap.org/listinfo/talk-ja > > > > > > -- > 岩崎 亘典 > > _______________________________________________ > Talk-ja mailing list > Talk-ja@openstreetmap.org <http://mc/compose?to=Talk-ja@openstreetmap.org> > http://lists.openstreetmap.org/listinfo/talk-ja > > > > > -- > Satoshi IIDA > mail: nyamp...@gmail.com <http://mc/compose?to=nyamp...@gmail.com> > twitter: @nyampire > > > > > -- > Satoshi IIDA > mail: nyamp...@gmail.com <http://mc/compose?to=nyamp...@gmail.com> > twitter: @nyampire > > > _______________________________________________ > Talk-ja mailing list > Talk-ja@openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-ja > > -- Satoshi IIDA mail: nyamp...@gmail.com twitter: @nyampire
_______________________________________________ Talk-ja mailing list Talk-ja@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ja
