サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
ノーベル賞
yellow-73.hatenablog.com
本記事は https://boiledorange73.hatenablog.com/entry/2013/12/09/000000 に移動しました。
はじめに これは、FOSS4G Advent Calendar (http://atnd.org/events/34052) 用の記事です。 ハードル上げないでね、と申し上げたのに、先に書かれた方々の中に裏切り者がおるorz 測地系 測地系は、ある位置を緯度経度であらわす際に用いる前提条件を指します。詳しくはgoogleさん等に聞いて下さい。 わが国では日本測地系(Tokyo)が2002年3月まで使用されてきましたが、2002年4月から世界測地系(JGD2000)に変わりました。また、GPSは日本測地系とも世界測地系とも異なる、WGS84という測地系を前提にしています。 これら3測地系のうち、WGS84とJGD2000はあまり差がない(WGS84は測地系パラメータの有効桁数を落としている)のでそのまま使ってもだいたいいいんですが、TokyoとJGD2000とは400mぐらいズレるので、この
今回のねらい http://strk.keybit.net/projects/postgis/Paris2011_TopologyWithPostGIS_2_0.pdf にある "Topology with PostGIS 2.0"の7,8枚目を見て、都道府県ポリゴンのsimplifyにトポロジを使えるのではないかと考えた次第。 Typmodさまさま ということで、既に格納している国土数値情報(行政区域)をゴニョゴニョしようとして、別データベースに移設しようとしました。 こういう場合はPostGIS 2.0では、PostgreSQLのpg_dumpを使って、データをダンプしてリストアしてやればOK。 pg_dump -t (テーブル名) (複写元データベース名) > (ファイル) psql (複写先データベース名) -f (ファイル) こんなかんじ。 これまでは、私の場合、pg_dump
ツイッターで http://blog.opengeo.org/2012/03/06/postgis-2-0-new-features-typmod/ が流れてきてました。 この文自体は読んでないのですが、PostGIS 2.0 から GEOMETRY型の Typmod になってるぜ、というものです。 AddGeometryColumns 使わなくていいようになった Typmod というのは、つまるところ… CREATE TABLE foo ( gid SERIAL PRIMARY KEY, geom GEOMETRY(Point, 4326) ); …でジオメトリカラムの生成が可能になるというもの。 以前は… CREATE TABLE foo ( gid SEIRAL PRIMARY KEY ); SELECT AddGeometryColumn('foo','geom',4326,'PO
今回は Advent Calendar 特別企画だ http://atnd.org/events/23085 参照。 http://d.hatena.ne.jp/waigani/20111210 とか http://d.hatena.ne.jp/wata909/20111211 が先行していて、ハードルが高まっていってるわけですが、気にしたら負け。 なので、いつものに近いようなことを書くことにしました。 ならいっそのこと「いつも通り」と称して、既に書いているエントリの日付を変えとこうかとも思いましたが、いやそんなことしたらさすがにマズいだろと思ったのですが、そんなに見られてないだろうから気づかれない可能性がかなりあるとも踏みましたが、えー、これ、本当に新規のエントリです。本当です。 それと、さすがに完全な個人メモではアレなかんじもするので、ほかの方が読まれるだろうことを、多少は考えて書くこ
Bluetoothでゴニョゴニョしようとしています。 とりあえずSDKのサンプルについてくる Bluetooth Chat をコンパイル、実行してみると、Androi端末間はうまくいった、というところまでは、随分前に来てました。 ひっかかったのが、パソコンとの通信。 スタックが問題なのか、開くCOMポートが違うのか、いろいろ考えても全く接続できない。 前にも見てた http://www.bright-sys.co.jp/blog/android-using-bluetooth-spp/ をもう一回見るけど分からん。 それで、とりあえず Bluetooth Chat をなんとなくステップ実行させていく。 … UUID て、何? BluetoothDevice#createRfcommSocketToServiceRecord(UUID) の引数の意味がなんとなく分からん。 で、先ほど紹介した
id:yellow_73:20110815 の続き。 センサの基準となる画面の向きはタブレットとスマートフォンで違う ヨー、ピッチ、ローについて、前の記事ではうそ書きましたー (差し替え済み)。平面に置いたのが基準です。 繰り返しですが、ポートレイトがセンサの基準になっているとは限りません。 getWindowManager().getDefaultDisplay().getRotation() で Surface.ROTATION_* (*は0, 90, 180, 270)が返ります。方位センサの基準からの回転角度と考えて差し支えないようです。 ヨー、ピッチ、ローの軸とねじの向き ヨー、ピッチ、ローについては、次のような感じです。 ヨー(Z軸)は矢印方向に左ねじで進み、ピッチ(X軸)、ロール(Y軸)は右ねじで進みます。 個人的な趣味と違う 個人的趣味はこんなかんじ。 つまり、右手系なのは
http://d.hatena.ne.jp/end0tknr/20110513 に猛然とチェックを入れさせてもらいます。 まず、被災地空中写真WMSはタイル化地図では使うべきではありません。 WMSはデスクトップGIS専用です.Google MapsやOpenLayers等でタイル化地図としてご使用になるのはご遠慮ください.代わりに,TMSをご使用ください. http://www.finds.jp/independent/tohoku/photo201103wms.html#WMS TMSとは http://wiki.osgeo.org/wiki/Tile_Map_Service_Specification 参照。タイル化された地図画像のURL生成規則と考えていただければ良いでしょう。これがまた Google Maps とは違う (Google Mapsは左手系でTMSは右手系) ので注意
id:end0tknr:20110518 に、ごめんなさい、再び絡ませてもらいます。 空間参照系 私もこのあたり素人なので的確性を欠くうえ、話自体が長くなるので、かなりいい加減な表現をします。 地図を重ね合わせた際にズレが無いようにするためには、重ね合わせる地図の座標系は完全に共通である必要があります。 この座標系を「空間参照系」と言います。 空間参照系は、たいたい「測地系」と「投影法」によって決まります。 測地系は、リアルな点を緯度、経度、標高で表現するための前提条件です。たとえば地球の形が違えば、同じ点を表現しても値が異なります。 投影法は、メルカトル図法だったり、モルワイデ図法だったり、です。投影法が異なると、同じ緯度、経度、標高でも地図上では異なる位置になります。 空間参照系コード 空間参照系は、かなりな数があります。日本国内を19個の系に分割しているものもあります。各国もバラバラ
遅いのは仕方ないと思ってた GDALの各種ツールは便利なんだけど、正直言って遅いよな、と思ってました。 一連のゴニョゴニョが複数走っている際は、どこかで何かが終わるので、あんまり気になりませんでした。 しかし、一連のゴニョゴニョが終わりに近づいて、ジョブが1本だけになった際、とうとう処理の遅さを感じてきました。 ちゃんと動かしてるんだろうなおい、と思って top で見てみると、ちゃんとトップに来てて、しっかり動いてました。 …いや、これおかしいやん。 使用メモリが極端に少ない。数GBの画像ファイル扱ってるくせして50MBぐらいしかメモリを占有してない。 ファイルアクセスは遅い 処理をしているうちに、どこかは知りませんが、中途のデータはファイルシステムに吐き出しているはず。ファイルへのアクセスの速度は、メモリへのアクセスと比べると全く比べものにならない。このメモリの少なさが実行速度低下の理由
id:yellow_73:20090701#p2 のつづき。 標題通り。 基盤地図情報の行政区域に対して、都道府県ごとにST_Unionをかけるというものです。 以前は…どうだったっけ…全県やろうとして10時間ぐらい放置しておいても終わらないから投げた記憶があります。 ジオメトリタイプがあわなくてエラーが出て、叩き込みまではできてませんが、エラー発生までで20分。少なくとも1県は終わってるってことです。 エラーを確認するために DISTINCT で GeometryType(ST_Union(the_geom)) をやって、半時間ぐらい。なお、原因はMULTIPOLYGONでなくPOLYGONになる県があったためでした。 あらためて、ST_Multiで強制的にMULTIPOLYGONにして叩き込むと、やはり30分で完了。 まじで速い。笑いが込み上げてくる。1桁どころの差じゃないぞこれ。
http://www.finds.jp/wsdocs/kibanwms/termsofuse.html 参照。 id:hfu さんが3月ごろにやられてたので、そのうち反応があると思います。 ていうか、hfuさんがやり出したからこそここにつながってます。
GTileLayer では、getTileUrl()の返り値を URL として画像を取りに行き、他のレイヤーと重ねてくれます。getTileUrl()は自前で実装する必要があります。また、これに連動する画像提供サーバも必要となります。 getTileUrl(point,zoom) で渡される引数 point と zoom の意味は、次の通りです。 pointは、GPoint型で、取得される画像単位(ピクセル単位ではない)での横位置、縦位置を示します。座標系は左上隅を原点としています。 zoomは、整数型で、値が1つ大きくなると、地図のサイズが2倍になります。 このため、point位置における画像の、地図全体から見たオフセット値(ピクセル単位)は X : point.x * 256 Y : point.y * 256 になります。 以前 X : point.x * 256 * 2**zoom
サイト移動しています 2014年以降の記事は https://boiledorange73.hatenablog.com/ に移動しています。 2013年以前の記事は はてなダイアリー から はてなブログ に移動しています。 本記事は https://boiledorange73.hatenablog.com/entry/2013/12/09/000000 に移動しました。 id:yellow_73:20130809とかid:yellow_73:20130814とかの続き。 https://twitter.com/tmizu23/statuses/363253994665152512 参照。 http://trac.osgeo.org/gdal/ticket/4379 で、マルチプロセス用パッチが出てたという。 同じようなこと考えてるんだ、20ヶ月も前にな。 困ってたガワも作ってらっしゃる
このページを最初にブックマークしてみませんか?
『ここのことはなかったことにするかも』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く