Re: [OSM-ja] KSJ2 re-import: Forest Data

2013-08-21 スレッド表示 Shu Higashi 
林さんGJ!分割賛成です。
2013/08/21 14:36 yuu hayashi hayashi@gmail.com:

 hayashi です。
 森林の再インポート／トレースについて

 巨大なマルチポリゴン・リレーションになっている森林データをメッシュ状に分割して非マルチポリゴン化するプログラムを開発中しているところです。
 まだリリースできるレベルではありませんが、「メッシュ分割」には成功しました。
 もう少しでリリースできるようになると思います。
 もうしばらくお待ちください。

 http://sourceforge.jp/users/yuuhayashi/pf/osmCutter/wiki/FrontPage

 上記URL（sourceforge)で作成中のプログラムを参照できます。
 （開発協力者募集中）

 ___
 Talk-ja mailing list
 Talk-ja@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/talk-ja


___
Talk-ja mailing list
Talk-ja@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-ja

Re: [OSM-ja] KSJ2 re-import: Forest Data

2013-08-21 スレッド表示 Satoshi IIDA 
いいだです。

既存の森林マルチポリゴンの分割は是非やりたいですね。

これから再インポートを試みているデータも、
二次メッシュでの分割はしているのですが。。。
こちらは完全に精度の問題なので、
単純にメッシュにするだけだと解決しないのが悩みどころです(´〜｀ )






2013年8月21日 16:08 Shu Higashi higa...@gmail.com:

 林さんGJ!分割賛成です。
 2013/08/21 14:36 yuu hayashi hayashi@gmail.com:

 hayashi です。
 森林の再インポート／トレースについて

 巨大なマルチポリゴン・リレーションになっている森林データをメッシュ状に分割して非マルチポリゴン化するプログラムを開発中しているところです。
 まだリリースできるレベルではありませんが、「メッシュ分割」には成功しました。
 もう少しでリリースできるようになると思います。
 もうしばらくお待ちください。

 http://sourceforge.jp/users/yuuhayashi/pf/osmCutter/wiki/FrontPage

 上記URL（sourceforge)で作成中のプログラムを参照できます。
 （開発協力者募集中）

 ___
 Talk-ja mailing list
 Talk-ja@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/talk-ja


 ___
 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

Re: [OSM-ja] KSJ2 re-import: Forest Data

2013-08-20 スレッド表示 yuu hayashi 
hayashi です。
森林の再インポート／トレースについて

巨大なマルチポリゴン・リレーションになっている森林データをメッシュ状に分割して非マルチポリゴン化するプログラムを開発中しているところです。
まだリリースできるレベルではありませんが、「メッシュ分割」には成功しました。
もう少しでリリースできるようになると思います。
もうしばらくお待ちください。

http://sourceforge.jp/users/yuuhayashi/pf/osmCutter/wiki/FrontPage

上記URL（sourceforge)で作成中のプログラムを参照できます。
（開発協力者募集中）
___
Talk-ja mailing list
Talk-ja@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-ja

Re: [OSM-ja] KSJ2 re-import: Forest Data

2013-08-16 スレッド表示 Satoshi IIDA 
いいだです。

 平成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
 .95505lat=34.93733zoom=14num=2mt0=mapnikmt1=bing-satellitehttp://tools.geofabrik.de/mc/?lon=133.95505lat=34.93733zoom=14num=2mt0=mapnikmt1=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.comhttp://mc/compose?to=nyamp...@gmail.com
 :


 いいだです。

 二次メッシュで分割したデータ、拝見しました。
 Multipolygon Relationのouter, innerもバッチリです！ ステキです！
 (欲を言えば、二次メッシュ部分でウェイが重複してるウェイがあるのですが、
 致命的ではありませんし、十分以上に利用可能なデータです)

 GRASSはぜんぜん触ったこと無いので
 こちらでの再現がどうにもスタックしていますが、少しトライしてみます。





 2013年7月8日 21:16 Nobusuke Iwasaki 
 wata...@gmail.comhttp://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.comhttp://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.orghttp://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

Re: [OSM-ja] KSJ2 re-import: Forest Data

2013-08-15 スレッド表示 Satoshi IIDA 
いいだです。

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:


 いいだです。

 二次メッシュで分割したデータ、拝見しました。
 Multipolygon Relationのouter, innerもバッチリです！ ステキです！
 (欲を言えば、二次メッシュ部分でウェイが重複してるウェイがあるのですが、
 致命的ではありませんし、十分以上に利用可能なデータです)

 GRASSはぜんぜん触ったこと無いので
 こちらでの再現がどうにもスタックしていますが、少しトライしてみます。





 2013年7月8日 21:16 Nobusuke Iwasaki wata...@gmail.com:

 いわさきです。

  ただ、2つのポリゴンが重複している部分で、ウェイ自体も重複しているなど、
  OSMデータとしては美しくないものになってしまいました(^^;
  あと多分、MultiPolygon Relationの outer, inner指定もちょっとおかしくなっている感じがします。

 なるほどです。
 その辺ちゃんとやろうとすると，ディゾルブをかけたりとか，なんとか，そういう処理が必要になるかな？
 おっしゃるとおり，可能な限り07のデータをつかって，問題になったときに対処しましょう。


  こちらも、交差処理自体は問題なく完了したのですが、
  OSM的にはエラーが大量であまり美しいとは言えないデータにな
  っており、そのまま使うのはちょっと難しそうです(^^;

 了解です。
 こちらの方は，GRASS GISで同じ処理したもの（島根）を，個別に送りますので，ちょっとそちらで確認していただけますでしょうか。
 よろしくお願いします。



 2013年7月8日 13:23 Satoshi IIDA nyamp...@gmail.com:
 
  いいだです。
 
  ありがとうございます！
 
  で、いただいた手順で実際にやってみました。
 
  ■複数Shapeファイルの結合
  検証用ということ事で，よろしいでしょうか。
  はい、検証用で使いました。
  いただいた手順で、
  Shapeファイル結合自体は無事うまくゆきました。
 
  ただ、2つのポリゴンが重複している部分で、ウェイ自体も重複しているなど、
  OSMデータとしては美しくないものになってしまいました(^^;
  あと多分、MultiPolygon Relationの outer, inner指定もちょっとおかしくなっている感じがします。
 
  これらは妥当性検証をかければ潰してゆくことができるのですが、
  単純に手間がかかってミスする可能性が高くなるので、あまりやりたくないのが正直なところです。
  可能な限り、07のデータを使うようにしたいな、と思っています。
 
  ■二次メッシュとの結合
  こちらも、交差処理自体は問題なく完了したのですが、
  OSM的にはエラーが大量であまり美しいとは言えないデータにな
  っており、
  そのまま使うのはちょっと難しそうです(^^;
 
  二次メッシュファイル自体を .osm化して、
  JOSM側でやったらうまいことできないかな、とも思っているので、もう少し考えてみます。
 
  分割は必須ではないと思っているので、できたら今週末くらいには作業したいなー。
 
 
  --
  Satoshi IIDA
  mail: nyamp...@gmail.com
  twitter: @nyampire
 
  ___
  Talk-ja mailing list
  Talk-ja@openstreetmap.org
  http://lists.openstreetmap.org/listinfo/talk-ja
 



 --
 岩崎 亘典

 ___
 Talk-ja mailing list
 Talk-ja@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/talk-ja




 --
 Satoshi IIDA
 mail: nyamp...@gmail.com
 twitter: @nyampire




-- 
Satoshi IIDA
mail: nyamp...@gmail.com
twitter: @nyampire
___
Talk-ja mailing list
Talk-ja@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-ja

Re: [OSM-ja] KSJ2 re-import: Forest Data

2013-07-10 スレッド表示 Satoshi IIDA 
いいだです。

二次メッシュで分割したデータ、拝見しました。
Multipolygon Relationのouter, innerもバッチリです！ ステキです！
(欲を言えば、二次メッシュ部分でウェイが重複してるウェイがあるのですが、
致命的ではありませんし、十分以上に利用可能なデータです)

GRASSはぜんぜん触ったこと無いので
こちらでの再現がどうにもスタックしていますが、少しトライしてみます。





2013年7月8日 21:16 Nobusuke Iwasaki wata...@gmail.com:

 いわさきです。

  ただ、2つのポリゴンが重複している部分で、ウェイ自体も重複しているなど、
  OSMデータとしては美しくないものになってしまいました(^^;
  あと多分、MultiPolygon Relationの outer, inner指定もちょっとおかしくなっている感じがします。

 なるほどです。
 その辺ちゃんとやろうとすると，ディゾルブをかけたりとか，なんとか，そういう処理が必要になるかな？
 おっしゃるとおり，可能な限り07のデータをつかって，問題になったときに対処しましょう。


  こちらも、交差処理自体は問題なく完了したのですが、
  OSM的にはエラーが大量であまり美しいとは言えないデータにな
  っており、そのまま使うのはちょっと難しそうです(^^;

 了解です。
 こちらの方は，GRASS GISで同じ処理したもの（島根）を，個別に送りますので，ちょっとそちらで確認していただけますでしょうか。
 よろしくお願いします。



 2013年7月8日 13:23 Satoshi IIDA nyamp...@gmail.com:
 
  いいだです。
 
  ありがとうございます！
 
  で、いただいた手順で実際にやってみました。
 
  ■複数Shapeファイルの結合
  検証用ということ事で，よろしいでしょうか。
  はい、検証用で使いました。
  いただいた手順で、
  Shapeファイル結合自体は無事うまくゆきました。
 
  ただ、2つのポリゴンが重複している部分で、ウェイ自体も重複しているなど、
  OSMデータとしては美しくないものになってしまいました(^^;
  あと多分、MultiPolygon Relationの outer, inner指定もちょっとおかしくなっている感じがします。
 
  これらは妥当性検証をかければ潰してゆくことができるのですが、
  単純に手間がかかってミスする可能性が高くなるので、あまりやりたくないのが正直なところです。
  可能な限り、07のデータを使うようにしたいな、と思っています。
 
  ■二次メッシュとの結合
  こちらも、交差処理自体は問題なく完了したのですが、
  OSM的にはエラーが大量であまり美しいとは言えないデータにな
  っており、
  そのまま使うのはちょっと難しそうです(^^;
 
  二次メッシュファイル自体を .osm化して、
  JOSM側でやったらうまいことできないかな、とも思っているので、もう少し考えてみます。
 
  分割は必須ではないと思っているので、できたら今週末くらいには作業したいなー。
 
 
  --
  Satoshi IIDA
  mail: nyamp...@gmail.com
  twitter: @nyampire
 
  ___
  Talk-ja mailing list
  Talk-ja@openstreetmap.org
  http://lists.openstreetmap.org/listinfo/talk-ja
 



 --
 岩崎 亘典

 ___
 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

Re: [OSM-ja] KSJ2 re-import: Forest Data

2013-07-08 スレッド表示 Nobusuke Iwasaki 
いわさきです。

 ただ、2つのポリゴンが重複している部分で、ウェイ自体も重複しているなど、
 OSMデータとしては美しくないものになってしまいました(^^;
 あと多分、MultiPolygon Relationの outer, inner指定もちょっとおかしくなっている感じがします。

なるほどです。
その辺ちゃんとやろうとすると，ディゾルブをかけたりとか，なんとか，そういう処理が必要になるかな？
おっしゃるとおり，可能な限り07のデータをつかって，問題になったときに対処しましょう。


 こちらも、交差処理自体は問題なく完了したのですが、
 OSM的にはエラーが大量であまり美しいとは言えないデータにな
 っており、そのまま使うのはちょっと難しそうです(^^;

了解です。
こちらの方は，GRASS GISで同じ処理したもの（島根）を，個別に送りますので，ちょっとそちらで確認していただけますでしょうか。
よろしくお願いします。



2013年7月8日 13:23 Satoshi IIDA nyamp...@gmail.com:

 いいだです。

 ありがとうございます！

 で、いただいた手順で実際にやってみました。

 ■複数Shapeファイルの結合
 検証用ということ事で，よろしいでしょうか。
 はい、検証用で使いました。
 いただいた手順で、
 Shapeファイル結合自体は無事うまくゆきました。

 ただ、2つのポリゴンが重複している部分で、ウェイ自体も重複しているなど、
 OSMデータとしては美しくないものになってしまいました(^^;
 あと多分、MultiPolygon Relationの outer, inner指定もちょっとおかしくなっている感じがします。

 これらは妥当性検証をかければ潰してゆくことができるのですが、
 単純に手間がかかってミスする可能性が高くなるので、あまりやりたくないのが正直なところです。
 可能な限り、07のデータを使うようにしたいな、と思っています。

 ■二次メッシュとの結合
 こちらも、交差処理自体は問題なく完了したのですが、
 OSM的にはエラーが大量であまり美しいとは言えないデータにな
 っており、
 そのまま使うのはちょっと難しそうです(^^;

 二次メッシュファイル自体を .osm化して、
 JOSM側でやったらうまいことできないかな、とも思っているので、もう少し考えてみます。

 分割は必須ではないと思っているので、できたら今週末くらいには作業したいなー。


 --
 Satoshi IIDA
 mail: nyamp...@gmail.com
 twitter: @nyampire

 ___
 Talk-ja mailing list
 Talk-ja@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/talk-ja




--
岩崎 亘典

___
Talk-ja mailing list
Talk-ja@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-ja

Re: [OSM-ja] KSJ2 re-import: Forest Data

2013-07-06 スレッド表示 Nobusuke Iwasaki 
飯田さん，みなさん

いわさきです。

 はい、ひとまずはこのように、方眼に区切った形にできればベターです。
 この機能ってどういう作業をされているのでしょうか。

QGISのインターセクトという機能を使っています。メニューだと，交差です。
手前勝手ですが，こちらにQGISのその辺を説明したスライドがあるので，ご参考に。
http://www.slideshare.net/wata909/qgis-advance-addition

今回は，国土数値情報と，２次メッシュを重ね合わせました。
http://ja.wikipedia.org/wiki/%E5%9C%B0%E5%9F%9F%E3%83%A1%E3%83%83%E3%82%B7%E3%83%A5

二次メッシュのデータは，mapconciergeさんのページからダウンロードできます ;-)
http://www.mapconcierge.jp/o/data/meshcode.html


 鳥取と大分で実施して、どちらも同様に異常終了します。
鳥取，大分ともに，07と08+09は同じ範囲なので特にやる必要はないとは思いますが，検証用ということ事で，よろしいでしょうか。

こちらもQGISでやろうとしたのですが，
Win8 64bit + QGIS1.8 OSGeo4W
だと異常終了し，
Win8 64bit + QGIS1.9 OSGeo4W
だとうまくいきました。

で，1.8でうまくやる方法ですが，結合をする前に，レイヤの上で右クリックして「名前をつけて保存」で，座標系でJGD2000を指定して下さい。
これでやると，うまくいきました。

つまり，DL下状態のshpファイルには座標系の情報がないので，保存するときにパニックをおこしていた，という感じのようです，たぶん。

もしくは，ogr2ogrを使って，
ogr2ogr forest.shp a001440020120309.shp
ogr2ogr forest.shp a001440020120308.shp -append

とやる手もあります。
元ファイルをforest.shpにコピーし，そいつに08を付与する，というイメージです。
ただこれだと，現行のogr2ogrだと文字コードがおかしくなってしまうので，あまりおすすめしません。

とにかく，まずは実際にデータの表示を行い，結合処理が必要かどうか確認したほうがいいですね。
ではでは。



2013年7月7日 0:09 Satoshi IIDA nyamp...@gmail.com:

 いいだです。

 2000Node以下にするのは，
 たとえばこんな風に分割するというイメージでしょうか？
 https://twitter.com/wata909/status/353377293982388226/photo/1

 はい、ひとまずはこのように、方眼に区切った形にできればベターです。
 この機能ってどういう作業をされているのでしょうか。
 なにかのスクリプトを組んで処理してる？
 (素人丸出しの質問ですみません。。)

 あと、1つのラインに属しているポイントを2000以下にする、というのは、
 JOSM側でわりと簡単にできるので、「できたらいいな」程度です。

 どうやら複数のファイルを結合した方が良さそうです。
 あー、やっぱりそういう県もあるんですね。

 そしてこちらの QGIS v1.8@Mac環境で
 「複数のShapeファイルを結合する」の機能を試してみているのですが、
 実行時にQGISが異常終了してしまいます orz

 やってることは以下サイトと同じ(CRSの指定だけWGS84に変更してる)なのですが。
 https://sites.google.com/site/qgisnoiriguchi/vector01/08

 鳥取と大分で実施して、どちらも同様に異常終了します。
 そちらの環境でも、結合ってできてますか？






 2013年7月6日 14:10 Nobusuke Iwasaki wata...@gmail.com:

 いいださん，みなさん

 いわさきです。
 マルチポリゴンにするのは，QGISできると思います。
 2000Node以下にするのは，たとえばこんな風に分割するというイメージでしょうか？
 https://twitter.com/wata909/status/353377293982388226/photo/1

 それから，KSJの森林レイヤなのですが，ちょっと癖がありそうです。
 島根のデータは問題ないのですが，たまたま開いた長野のデータが以下のような感じになってました。
 07 森林地域　http://t.co/u7L4F0Xpzx
 08 国有林　http://t.co/5TT0Di18p2
 09 地域森林計画対象民有林　http://t.co/nGsndzY7rY
 10 保安林　http://t.co/xRXJxcTCcD
 7〜10を重ねたもの　http://t.co/D5BWjTzGSh

 最初の数字は，shpファイルの最後の二桁です。
 これを見ると，どうやら複数のファイルを結合した方が良さそうです。
 長野の場合は08と09を重ねると良さそうです。ただし，長野のデータだけがエラーなのかもしれませんが。

 参考までに。

 2013年7月6日 1:24 Satoshi IIDA nyamp...@gmail.com:
 
  いいだです。
 
  タグのルール変換はともかくとして、ogr2osmで森林データ変換をやってみました。
  純粋にコンバートするだけなら、以下の叩き方でゆけます。
  (pythonのdefault encodingはUTF-8にしてあります)
 
  ./ogr2osm.py --encoding=shift_jis
  ./shape/A13-11_31_GML/a001310020120307.shp
 
 
  ■小さなマルチポリゴンへの自動切り分けはできません。
  たぶん、Shapeファイルの段階でQGISなどを使って方眼状に切り分けてから、
  ogr2osmで変換するなどの処理が必要なのじゃないかな、とおもいます。
  (ほんとにQGISなどでできるかはわからないですが。。。)
 
  なので、少なくとも投入直後に巨大リレーションになってしまうのは、
  元ファイルの作りからしてある程度は仕方がないかなぁ、というのが僕の意見です。
  できれば、細かいマルチポリゴンに分割してしまいたいのはやまやまなのですが。
 
  3−4分割くらいなら手動でもそんなに手間がかからないのですけれど、
  方眼上に分けるなど、システマチックにやるには
  どうやればよいのか、ちょっと見当がついていません。
 
  ■2000Node制限には対応していません
  そういえば、OSMの地味な制限として、
  1つのウェイに参加できるのは2000Nodeまで、という制限があります。
  (JOSM経由でアップロードするとき、エラーが表示されます)
 
  ここは2000Node以下になるように手動でウェイ分割をしてあげる必要がありそうです。
 
 
 
 
  2013年7月5日 23:39 Tomomichi Hayakawa tom.hayak...@gmail.com:
 
  Tomです。
 
  前回のインポートでは、
  巨大なリレーションが出来るのが、いろいろ問題の種でした。
  ogr2osmは、どうなんでしょうね？
  確認しておきたいですね。
 
  小さなオブジェクトに変換してくれるのなら、
  他の地域にも使ってみたい気もします。
 
 
  2013年7月5日 14:52 Satoshi IIDA nyamp...@gmail.com:
  
   いいだです。
  
   ライセンス切り替えによるデータ削除から約1年が経過しました。
   御存知の通り、切り替えに伴ってKSJ2データの多くが削除されており、
   いくつかは再インポートの必要があると考えています。
  
   その中でも特に目立つものとして、
   まずは西日本の森林データを再度インポートしたいと思っています。
   以下の要領で行おうかな、と思っているのですが、ご意見をください。
  
   ■利用するデータ
   KSJ2 森林面積データ、
   現時点での最新（鳥取県データをみたら、平成23年度）を考えています。
   前回インポート時は、平成18年データが主なようです。
  
   http://nlftp.mlit.go.jp/ksj/gml/datalist/KsjTmplt-A13.html
  
   ■付与するタグ
   タグについては以下で示されている通り、
   Nodeへの付与はせず、WayやRelationへ適用します。
   http://wiki.openstreetmap.org/wiki/Import/Catalogue/Japan_KSJ2_Import
  
   source = KSJ2/A13
   source_ref =
   http://wiki.openstreetmap.org/wiki/Import/Catalogue/Japan_KSJ2_Import
   note:ja = 国土数値情報（森林地域）平成23年　国土交通省
   natural = wood
  
   自然林(natural=wood)と人工林(landuse=forest)の違いは常に悩ましいポイントですが、
   基本的にすべて自然林(natural=wood)で行いたいとおもいます。
   以下の区分で示されている、1 森林地帯を変換するイメージです。
   http://nlftp.mlit.go.jp/ksj/gml/codelist/ForestAreaCd.html
  
   ■データ形式変換
   ogr2osmという、shape - .osmの変換スクリプトで行おうと思っています。
   タグの変換を柔軟に行うことができるのが大きな特徴です。
   https://github.com/pnorman/ogr2osm
  
   以前に行政区境の変換を行った時に使った実績があり、
   2byte文字(UTF-8)での出力もOKです。
   実行には、以下のような変換ルールを書く必要があります。
  
  
   https://github.com/nyampire/ogr2osm/blob/master/translations/N03-admin_border.py
  
   こんなかんじの行を書けば大丈夫かな、と思っています。
  
   # 基本のタグ付け
   tags.update({'source':'KSJ2/A13'})
   tags.update({'note:ja':u'国土数値情報（森林地域）平成23年　国土交通省'})
  
  
  
   tags.update({'source_ref':'http://wiki.openstreetmap.org/wiki/Import/Catalogue/Japan_KSJ2_Import'})
   tags.update({'natural':'wood'})
  
   また、元データはShapeファイルで配布されていますので、
   実は、JOSMのOpenDataプラグインを利用すればそのまま読み込むことが可能だったりします。
   ただし、利用されるタグ情報はDBFファイルに定義されたままの状態になりますので、

Re: [OSM-ja] KSJ2 re-import: Forest Data

2013-07-05 スレッド表示 Tomomichi Hayakawa 
Tomです。

前回のインポートでは、
巨大なリレーションが出来るのが、いろいろ問題の種でした。
ogr2osmは、どうなんでしょうね？
確認しておきたいですね。

小さなオブジェクトに変換してくれるのなら、
他の地域にも使ってみたい気もします。


2013年7月5日 14:52 Satoshi IIDA nyamp...@gmail.com:

 いいだです。

 ライセンス切り替えによるデータ削除から約1年が経過しました。
 御存知の通り、切り替えに伴ってKSJ2データの多くが削除されており、
 いくつかは再インポートの必要があると考えています。

 その中でも特に目立つものとして、
 まずは西日本の森林データを再度インポートしたいと思っています。
 以下の要領で行おうかな、と思っているのですが、ご意見をください。

 ■利用するデータ
 KSJ2 森林面積データ、
 現時点での最新（鳥取県データをみたら、平成23年度）を考えています。
 前回インポート時は、平成18年データが主なようです。

 http://nlftp.mlit.go.jp/ksj/gml/datalist/KsjTmplt-A13.html

 ■付与するタグ
 タグについては以下で示されている通り、
 Nodeへの付与はせず、WayやRelationへ適用します。
 http://wiki.openstreetmap.org/wiki/Import/Catalogue/Japan_KSJ2_Import

 source = KSJ2/A13
 source_ref =
 http://wiki.openstreetmap.org/wiki/Import/Catalogue/Japan_KSJ2_Import
 note:ja = 国土数値情報（森林地域）平成23年　国土交通省
 natural = wood

 自然林(natural=wood)と人工林(landuse=forest)の違いは常に悩ましいポイントですが、
 基本的にすべて自然林(natural=wood)で行いたいとおもいます。
 以下の区分で示されている、1 森林地帯を変換するイメージです。
 http://nlftp.mlit.go.jp/ksj/gml/codelist/ForestAreaCd.html

 ■データ形式変換
 ogr2osmという、shape - .osmの変換スクリプトで行おうと思っています。
 タグの変換を柔軟に行うことができるのが大きな特徴です。
 https://github.com/pnorman/ogr2osm

 以前に行政区境の変換を行った時に使った実績があり、
 2byte文字(UTF-8)での出力もOKです。
 実行には、以下のような変換ルールを書く必要があります。
 https://github.com/nyampire/ogr2osm/blob/master/translations/N03-admin_border.py

 こんなかんじの行を書けば大丈夫かな、と思っています。

 # 基本のタグ付け
 tags.update({'source':'KSJ2/A13'})
 tags.update({'note:ja':u'国土数値情報（森林地域）平成23年　国土交通省'})

 tags.update({'source_ref':'http://wiki.openstreetmap.org/wiki/Import/Catalogue/Japan_KSJ2_Import'})
 tags.update({'natural':'wood'})

 また、元データはShapeファイルで配布されていますので、
 実は、JOSMのOpenDataプラグインを利用すればそのまま読み込むことが可能だったりします。
 ただし、利用されるタグ情報はDBFファイルに定義されたままの状態になりますので、
 いったんすべて削除した後で上記のタグを埋め込む作業が必要です。
 手動作業だとミスがでる可能性があるので、ogr2osmを主に利用する予定です。

 ■管理について
 以前に作成されたテーブルへカラムを追加して、
 再インポートを行ったかどうかをチェックすればよいかと思っています。
 http://wiki.openstreetmap.org/wiki/Import/Catalogue/Japan_KSJ2_Import/Forest


 もっとよさそうなやり方や、方法の疑問点など、
 ご意見いただけると嬉しいです。


 --
 Satoshi IIDA
 mail: nyamp...@gmail.com
 twitter: @nyampire

 ___
 Talk-ja mailing list
 Talk-ja@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/talk-ja




-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
早川知道 (Tomomichi Hayakawa) tom.hayak...@gmail.com

うえこみ春日井小牧 - http://www.kasugai-komaki.jp/
Malaika System - http://malaika-system.com/
blog - close to you - http://malaika.air-nifty.com/
OSM Tokai - http://groups.google.com/group/OSM-Tokai
XOOPS Cube TOKAI - http://xc-tokai.net/
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

___
Talk-ja mailing list
Talk-ja@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-ja

Re: [OSM-ja] KSJ2 re-import: Forest Data

2013-07-05 スレッド表示 Satoshi IIDA 
いいだです。

タグのルール変換はともかくとして、ogr2osmで森林データ変換をやってみました。
純粋にコンバートするだけなら、以下の叩き方でゆけます。
(pythonのdefault encodingはUTF-8にしてあります)

./ogr2osm.py --encoding=shift_jis
./shape/A13-11_31_GML/a001310020120307.shp


■小さなマルチポリゴンへの自動切り分けはできません。
たぶん、Shapeファイルの段階でQGISなどを使って方眼状に切り分けてから、
ogr2osmで変換するなどの処理が必要なのじゃないかな、とおもいます。
(ほんとにQGISなどでできるかはわからないですが。。。)

なので、少なくとも投入直後に巨大リレーションになってしまうのは、
元ファイルの作りからしてある程度は仕方がないかなぁ、というのが僕の意見です。
できれば、細かいマルチポリゴンに分割してしまいたいのはやまやまなのですが。

3−4分割くらいなら手動でもそんなに手間がかからないのですけれど、
方眼上に分けるなど、システマチックにやるには
どうやればよいのか、ちょっと見当がついていません。

■2000Node制限には対応していません
そういえば、OSMの地味な制限として、
1つのウェイに参加できるのは2000Nodeまで、という制限があります。
(JOSM経由でアップロードするとき、エラーが表示されます)

ここは2000Node以下になるように手動でウェイ分割をしてあげる必要がありそうです。




2013年7月5日 23:39 Tomomichi Hayakawa tom.hayak...@gmail.com:

 Tomです。

 前回のインポートでは、
 巨大なリレーションが出来るのが、いろいろ問題の種でした。
 ogr2osmは、どうなんでしょうね？
 確認しておきたいですね。

 小さなオブジェクトに変換してくれるのなら、
 他の地域にも使ってみたい気もします。


 2013年7月5日 14:52 Satoshi IIDA nyamp...@gmail.com:
 
  いいだです。
 
  ライセンス切り替えによるデータ削除から約1年が経過しました。
  御存知の通り、切り替えに伴ってKSJ2データの多くが削除されており、
  いくつかは再インポートの必要があると考えています。
 
  その中でも特に目立つものとして、
  まずは西日本の森林データを再度インポートしたいと思っています。
  以下の要領で行おうかな、と思っているのですが、ご意見をください。
 
  ■利用するデータ
  KSJ2 森林面積データ、
  現時点での最新（鳥取県データをみたら、平成23年度）を考えています。
  前回インポート時は、平成18年データが主なようです。
 
  http://nlftp.mlit.go.jp/ksj/gml/datalist/KsjTmplt-A13.html
 
  ■付与するタグ
  タグについては以下で示されている通り、
  Nodeへの付与はせず、WayやRelationへ適用します。
  http://wiki.openstreetmap.org/wiki/Import/Catalogue/Japan_KSJ2_Import
 
  source = KSJ2/A13
  source_ref =
  http://wiki.openstreetmap.org/wiki/Import/Catalogue/Japan_KSJ2_Import
  note:ja = 国土数値情報（森林地域）平成23年 国土交通省
  natural = wood
 
  自然林(natural=wood)と人工林(landuse=forest)の違いは常に悩ましいポイントですが、
  基本的にすべて自然林(natural=wood)で行いたいとおもいます。
  以下の区分で示されている、1 森林地帯を変換するイメージです。
  http://nlftp.mlit.go.jp/ksj/gml/codelist/ForestAreaCd.html
 
  ■データ形式変換
  ogr2osmという、shape - .osmの変換スクリプトで行おうと思っています。
  タグの変換を柔軟に行うことができるのが大きな特徴です。
  https://github.com/pnorman/ogr2osm
 
  以前に行政区境の変換を行った時に使った実績があり、
  2byte文字(UTF-8)での出力もOKです。
  実行には、以下のような変換ルールを書く必要があります。
 
 https://github.com/nyampire/ogr2osm/blob/master/translations/N03-admin_border.py
 
  こんなかんじの行を書けば大丈夫かな、と思っています。
 
  # 基本のタグ付け
  tags.update({'source':'KSJ2/A13'})
  tags.update({'note:ja':u'国土数値情報（森林地域）平成23年 国土交通省'})
 
  tags.update({'source_ref':'
 http://wiki.openstreetmap.org/wiki/Import/Catalogue/Japan_KSJ2_Import'})
  tags.update({'natural':'wood'})
 
  また、元データはShapeファイルで配布されていますので、
  実は、JOSMのOpenDataプラグインを利用すればそのまま読み込むことが可能だったりします。
  ただし、利用されるタグ情報はDBFファイルに定義されたままの状態になりますので、
  いったんすべて削除した後で上記のタグを埋め込む作業が必要です。
  手動作業だとミスがでる可能性があるので、ogr2osmを主に利用する予定です。
 
  ■管理について
  以前に作成されたテーブルへカラムを追加して、
  再インポートを行ったかどうかをチェックすればよいかと思っています。
 
 http://wiki.openstreetmap.org/wiki/Import/Catalogue/Japan_KSJ2_Import/Forest
 
 
  もっとよさそうなやり方や、方法の疑問点など、
  ご意見いただけると嬉しいです。
 
 
  --
  Satoshi IIDA
  mail: nyamp...@gmail.com
  twitter: @nyampire
 
  ___
  Talk-ja mailing list
  Talk-ja@openstreetmap.org
  http://lists.openstreetmap.org/listinfo/talk-ja
 



 --
 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 早川知道 (Tomomichi Hayakawa) tom.hayak...@gmail.com

 うえこみ春日井小牧 - http://www.kasugai-komaki.jp/
 Malaika System - http://malaika-system.com/
 blog - close to you - http://malaika.air-nifty.com/
 OSM Tokai - http://groups.google.com/group/OSM-Tokai
 XOOPS Cube TOKAI - http://xc-tokai.net/
 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

 ___
 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

Re: [OSM-ja] KSJ2 re-import: Forest Data

2013-07-05 スレッド表示 Nobusuke Iwasaki 
いいださん，みなさん

いわさきです。
マルチポリゴンにするのは，QGISできると思います。
2000Node以下にするのは，たとえばこんな風に分割するというイメージでしょうか？
https://twitter.com/wata909/status/353377293982388226/photo/1

それから，KSJの森林レイヤなのですが，ちょっと癖がありそうです。
島根のデータは問題ないのですが，たまたま開いた長野のデータが以下のような感じになってました。
07 森林地域　http://t.co/u7L4F0Xpzx
08 国有林　http://t.co/5TT0Di18p2
09 地域森林計画対象民有林　http://t.co/nGsndzY7rY
10 保安林　http://t.co/xRXJxcTCcD
7〜10を重ねたもの　http://t.co/D5BWjTzGSh

最初の数字は，shpファイルの最後の二桁です。
これを見ると，どうやら複数のファイルを結合した方が良さそうです。
長野の場合は08と09を重ねると良さそうです。ただし，長野のデータだけがエラーなのかもしれませんが。

参考までに。

2013年7月6日 1:24 Satoshi IIDA nyamp...@gmail.com:

 いいだです。

 タグのルール変換はともかくとして、ogr2osmで森林データ変換をやってみました。
 純粋にコンバートするだけなら、以下の叩き方でゆけます。
 (pythonのdefault encodingはUTF-8にしてあります)

 ./ogr2osm.py --encoding=shift_jis ./shape/A13-11_31_GML/a001310020120307.shp


 ■小さなマルチポリゴンへの自動切り分けはできません。
 たぶん、Shapeファイルの段階でQGISなどを使って方眼状に切り分けてから、
 ogr2osmで変換するなどの処理が必要なのじゃないかな、とおもいます。
 (ほんとにQGISなどでできるかはわからないですが。。。)

 なので、少なくとも投入直後に巨大リレーションになってしまうのは、
 元ファイルの作りからしてある程度は仕方がないかなぁ、というのが僕の意見です。
 できれば、細かいマルチポリゴンに分割してしまいたいのはやまやまなのですが。

 3−4分割くらいなら手動でもそんなに手間がかからないのですけれど、
 方眼上に分けるなど、システマチックにやるには
 どうやればよいのか、ちょっと見当がついていません。

 ■2000Node制限には対応していません
 そういえば、OSMの地味な制限として、
 1つのウェイに参加できるのは2000Nodeまで、という制限があります。
 (JOSM経由でアップロードするとき、エラーが表示されます)

 ここは2000Node以下になるように手動でウェイ分割をしてあげる必要がありそうです。




 2013年7月5日 23:39 Tomomichi Hayakawa tom.hayak...@gmail.com:

 Tomです。

 前回のインポートでは、
 巨大なリレーションが出来るのが、いろいろ問題の種でした。
 ogr2osmは、どうなんでしょうね？
 確認しておきたいですね。

 小さなオブジェクトに変換してくれるのなら、
 他の地域にも使ってみたい気もします。


 2013年7月5日 14:52 Satoshi IIDA nyamp...@gmail.com:
 
  いいだです。
 
  ライセンス切り替えによるデータ削除から約1年が経過しました。
  御存知の通り、切り替えに伴ってKSJ2データの多くが削除されており、
  いくつかは再インポートの必要があると考えています。
 
  その中でも特に目立つものとして、
  まずは西日本の森林データを再度インポートしたいと思っています。
  以下の要領で行おうかな、と思っているのですが、ご意見をください。
 
  ■利用するデータ
  KSJ2 森林面積データ、
  現時点での最新（鳥取県データをみたら、平成23年度）を考えています。
  前回インポート時は、平成18年データが主なようです。
 
  http://nlftp.mlit.go.jp/ksj/gml/datalist/KsjTmplt-A13.html
 
  ■付与するタグ
  タグについては以下で示されている通り、
  Nodeへの付与はせず、WayやRelationへ適用します。
  http://wiki.openstreetmap.org/wiki/Import/Catalogue/Japan_KSJ2_Import
 
  source = KSJ2/A13
  source_ref =
  http://wiki.openstreetmap.org/wiki/Import/Catalogue/Japan_KSJ2_Import
  note:ja = 国土数値情報（森林地域）平成23年　国土交通省
  natural = wood
 
  自然林(natural=wood)と人工林(landuse=forest)の違いは常に悩ましいポイントですが、
  基本的にすべて自然林(natural=wood)で行いたいとおもいます。
  以下の区分で示されている、1 森林地帯を変換するイメージです。
  http://nlftp.mlit.go.jp/ksj/gml/codelist/ForestAreaCd.html
 
  ■データ形式変換
  ogr2osmという、shape - .osmの変換スクリプトで行おうと思っています。
  タグの変換を柔軟に行うことができるのが大きな特徴です。
  https://github.com/pnorman/ogr2osm
 
  以前に行政区境の変換を行った時に使った実績があり、
  2byte文字(UTF-8)での出力もOKです。
  実行には、以下のような変換ルールを書く必要があります。
 
  https://github.com/nyampire/ogr2osm/blob/master/translations/N03-admin_border.py
 
  こんなかんじの行を書けば大丈夫かな、と思っています。
 
  # 基本のタグ付け
  tags.update({'source':'KSJ2/A13'})
  tags.update({'note:ja':u'国土数値情報（森林地域）平成23年　国土交通省'})
 
 
  tags.update({'source_ref':'http://wiki.openstreetmap.org/wiki/Import/Catalogue/Japan_KSJ2_Import'})
  tags.update({'natural':'wood'})
 
  また、元データはShapeファイルで配布されていますので、
  実は、JOSMのOpenDataプラグインを利用すればそのまま読み込むことが可能だったりします。
  ただし、利用されるタグ情報はDBFファイルに定義されたままの状態になりますので、
  いったんすべて削除した後で上記のタグを埋め込む作業が必要です。
  手動作業だとミスがでる可能性があるので、ogr2osmを主に利用する予定です。
 
  ■管理について
  以前に作成されたテーブルへカラムを追加して、
  再インポートを行ったかどうかをチェックすればよいかと思っています。
 
  http://wiki.openstreetmap.org/wiki/Import/Catalogue/Japan_KSJ2_Import/Forest
 
 
  もっとよさそうなやり方や、方法の疑問点など、
  ご意見いただけると嬉しいです。
 
 
  --
  Satoshi IIDA
  mail: nyamp...@gmail.com
  twitter: @nyampire
 
  ___
  Talk-ja mailing list
  Talk-ja@openstreetmap.org
  http://lists.openstreetmap.org/listinfo/talk-ja
 



 --
 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 早川知道 (Tomomichi Hayakawa) tom.hayak...@gmail.com

 うえこみ春日井小牧 - http://www.kasugai-komaki.jp/
 Malaika System - http://malaika-system.com/
 blog - close to you - http://malaika.air-nifty.com/
 OSM Tokai - http://groups.google.com/group/OSM-Tokai
 XOOPS Cube TOKAI - http://xc-tokai.net/
 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

 ___
 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




-- 
岩崎 亘典

___
Talk-ja mailing list
Talk-ja@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-ja

[OSM-ja] KSJ2 re-import: Forest Data

2013-07-04 スレッド表示 Satoshi IIDA 
いいだです。

ライセンス切り替えによるデータ削除から約1年が経過しました。
御存知の通り、切り替えに伴ってKSJ2データの多くが削除されており、
いくつかは再インポートの必要があると考えています。

その中でも特に目立つものとして、
まずは西日本の森林データを再度インポートしたいと思っています。
以下の要領で行おうかな、と思っているのですが、ご意見をください。

■利用するデータ
KSJ2 森林面積データ、
現時点での最新（鳥取県データをみたら、平成23年度）を考えています。
前回インポート時は、平成18年データが主なようです。

http://nlftp.mlit.go.jp/ksj/gml/datalist/KsjTmplt-A13.html

■付与するタグ
タグについては以下で示されている通り、
Nodeへの付与はせず、WayやRelationへ適用します。
http://wiki.openstreetmap.org/wiki/Import/Catalogue/Japan_KSJ2_Import

source = KSJ2/A13
source_ref =
http://wiki.openstreetmap.org/wiki/Import/Catalogue/Japan_KSJ2_Import
note:ja = 国土数値情報（森林地域）平成23年 国土交通省
natural = wood

自然林(natural=wood)と人工林(landuse=forest)の違いは常に悩ましいポイントですが、
基本的にすべて自然林(natural=wood)で行いたいとおもいます。
以下の区分で示されている、1 森林地帯を変換するイメージです。
http://nlftp.mlit.go.jp/ksj/gml/codelist/ForestAreaCd.html

■データ形式変換
ogr2osmという、shape - .osmの変換スクリプトで行おうと思っています。
タグの変換を柔軟に行うことができるのが大きな特徴です。
https://github.com/pnorman/ogr2osm

以前に行政区境の変換を行った時に使った実績があり、
2byte文字(UTF-8)での出力もOKです。
実行には、以下のような変換ルールを書く必要があります。
https://github.com/nyampire/ogr2osm/blob/master/translations/N03-admin_border.py

こんなかんじの行を書けば大丈夫かな、と思っています。

# 基本のタグ付け
tags.update({'source':'KSJ2/A13'})
tags.update({'note:ja':u'国土数値情報（森林地域）平成23年 国土交通省'})
tags.update({'source_ref':'
http://wiki.openstreetmap.org/wiki/Import/Catalogue/Japan_KSJ2_Import'})
tags.update({'natural':'wood'})

また、元データはShapeファイルで配布されていますので、
実は、JOSMのOpenDataプラグインを利用すればそのまま読み込むことが可能だったりします。
ただし、利用されるタグ情報はDBFファイルに定義されたままの状態になりますので、
いったんすべて削除した後で上記のタグを埋め込む作業が必要です。
手動作業だとミスがでる可能性があるので、ogr2osmを主に利用する予定です。

■管理について
以前に作成されたテーブルへカラムを追加して、
再インポートを行ったかどうかをチェックすればよいかと思っています。
http://wiki.openstreetmap.org/wiki/Import/Catalogue/Japan_KSJ2_Import/Forest


もっとよさそうなやり方や、方法の疑問点など、
ご意見いただけると嬉しいです。


-- 
Satoshi IIDA
mail: nyamp...@gmail.com
twitter: @nyampire
___
Talk-ja mailing list
Talk-ja@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-ja