国土地理院提供の被災地の空中写真をFlickerに。経緯度はここに。 - Relevant, Timely, and Accurate
計画停電によるリスクをヘッジするための個人的試みとして、国土地理院提供の被災地の空中写真をダウンロードしたものFlickerに、経緯度はここにミラーします。 被災地の空中写真 http://www.flickr.com/photos/53691961@N03/sets/72157626132299003/ 空中写真の代表点の経緯度 上記の Flicker のファイル名との対応表です。 sendai_CTO-2010-4-C04_0003.jpg,141.0475196,38.30455228 sendai_CTO-2010-4-C04_0004.jpg,141.0432005,38.30126474 sendai_CTO-2010-4-C04_0005.jpg,141.038967,38.29792433 sendai_CTO-2010-4-C04_0006.jpg,141.034743,
「霞ヶ関→霞が関」の町名変更について簡単に推測してみる。 - Relevant, Timely, and Accurate
町名「霞が関」は昭和42年4月の住居表示実施をきっかけに「霞ヶ関」から変更されたのではないでしょうか。手近にあるツールを使って情報を集めてみました。 事実の確認 世の中で出ている地図の類で、町名の注記は「霞が関」となっていることを確認しました。一方で、東京メトロの駅名は「霞ケ関」となっています。よく言われているように、駅名付与時点での町名がこのようであったのではないでしょうか。 町名変更の機会 千代田区総合ホームページの「千代田区における住居表示の実施」には、昭和４２．４に霞が関一〜三丁目について住居表示が実施されたとされています（http://www.city.chiyoda.lg.jp/service/00086/d0008661.html）。町名（地方自治法における町又は字の名称）の変更には議会の議決が必要であり、町名の変更が行われることは頻繁ではないことを考えると、「霞ヶ関」から「
経緯度とGoogle Mercatorとの変換式を確認してみる（OpenLayers & Proj4js）。 - Relevant, Timely, and Accurate
既存の JavaScript プログラムに埋め込まれた、経緯度とGoogle Mercatorとの変換式（特にメルカトルから経緯度への逆変換式）を確認してみました。Safari の Web インスペクタを使って簡単に調べてみます。 基本的方法 Safari や Chrome に付属している Web インスペクタには「コンソール」があります。ここに JavaScript コードを書き込むと、そのページでロードされている JavaScript オブジェクトに簡単にアクセスすることができます。Ruby の irb を使うように、Web インスペクタコンソールを使って、JavaScript プログラムを理解していきます。 OpenLayers の場合 http://trac.openlayers.org/wiki/SphericalMercator を読むと結局、OpenLayers.Layer.
「地物」を概念世界のものと定義したことが生む躓きについて - Relevant, Timely, and Accurate
地理情報の国際標準化においては「地物」を概念世界のものと定義しています。しかし、この最も基本的な定義が、すでに躓きの石だったのです *1。 従来、「地物」は現実世界のものであった。 地理情報に携わる人々の間で話をしていると、地物が概念世界のものとして定義されているのか、現実世界のものとして定義されているのか、用語の定義で混乱を生じることがあります。概念世界のものと認識している人は情報系の人が多く、現実世界のものと認識している人は伝統的な測量についての知識が豊富な人が多いようです。この混乱は、次のことが理由だと考えています。 地理情報の国際標準化の世界では、地物(feature)は「実世界の現象の抽象概念(abstraction of real world phenomena)」と定義されているそうです。つまり、地物は概念世界のものとして定義されています。 一方で、地物を現実世界のものとして
「分かりやすい平面直角座標系」の Ruby 実装 - Relevant, Timely, and Accurate
市区町村コードから平面直角座標系の系の番号や EPSG コードを得る Ruby コードです。 誰かが公開しておくと多くの人（公開した人も含め）の手間が減りそうなので、ここに置いておきます。cc2epsg.rb という名前にしたいと思います。cc は city code の意味です。 コード本文にも書きましたが無保証である点よろしくお願いします。北海道と鹿児島県と沖縄県で else で逃げているところがあるので、特にそのあたりにバグが入り込んでいる余地があるかも知れません。 # cc2espg.rb: Ruby implementation of # http://vldb.gsi.go.jp/sokuchi/patchjgd/download/Help/jpc/jpc.htm#sansho # Usage of the works is permitted provided that th
地図調製業各社の決算短信を読む - Relevant, Timely, and Accurate
日本地図調製業協会会員の会社について、Web でアクセスできる決算短信の中からトピックを箇条書きで抜き出すとどうなるか、実際にやってみました。 日本地図調製業協会の会員名簿（http://www.chichokyo.or.jp/about/member.html）からたどって見つけ出せる最新の決算短信から、定性的情報を斜め読みしてトピックを抽出してみました。 株式会社きもと 丸山工場の増設工事が７月に完成。９月から新規設備が本格稼働。 モバイル向けハードコートフィルムの売上増大。 中央省庁向け受託作業の売上が増加。 株式会社昭文社 携帯サービス関連収入、PND向けソフト・コンテンツが順調に伸びる。 「1000円ドライブ」シリーズがヒット。 コスト削減、人件費削減、減損処理に伴う償却費減少効果。損益は大幅改善。 「MAPPLEnavi」の採用増大で売上高増加。 「ことりっぷ」のコンビニ販売。
英国地図作成機関 Ordnance Survey の地図データが４月から無償化 - Relevant, Timely, and Accurate
英国では１万以上で５万に満たない地図情報は無償で公開する模様です。ゴードン・ブラウン首相が直接アナウンスしています。 ゴードン・ブラウン首相の２つ隣に座っている（下の Youtube 動画の初期画面に出ている）のは World Wide Web の 考案開発者 Sir Timothy John Berners-Lee です。ビデオの中で彼も話をします。豪華キャストです。 http://www.communities.gov.uk/news/corporate/1385429 選挙区の境界 自治体の境界 郵便番号 中縮尺地図情報 を公開するようなことが書かれています。これに対して、Ed Parsons さんは Ordnance Survey のデータはその希少性ではなく普及度から生まれることに早く気づくべきだった。 http://www.edparsons.com/2009/11/now-w
グリッドとしても座標表現としても使える Geohash - Relevant, Timely, and Accurate
自由に使える経緯度の符号化法 Geohash がグリッドとしても座標表現としても使えてうれしいです。 Geohash とは？ Geohash (http://en.wikipedia.org/wiki/Geohash) が色々と使われているようです(http://zcologia.com/news/759/geohash-and-bigtable/) 。 この Geohash、ビット列を経度・緯度の順に交代に2分割するように解釈し、BASE32 で符号化するもので、Wikipedia の短い記事で仕様が完結しており、自由に使えます。 この Geohash、よく考えられていると思います。Geohash は点を表現するものですが、その点と同じ Geohash を持つ面のグリッドであると解釈することも簡単です。グリッドと座標の表現を、Geohash 一つで済ますことができます。 Geohash
geo+webの人は皆「RESTful Web サービス」を買うべき - Relevant, Timely, and Accurate
d:id:hfu:20090316 に対するはてなブックマークで、yohei さんにコメントをいただきました。 任意矩形をquery paramsで取得するのはRESTfulに設計できます(RWS第5章)。サーバ内部の処理とインターフェース設計はまずは別に考えるべきと思います。 http://b.hatena.ne.jp/entry/http://d.hatena.ne.jp/hfu/20090316/1237148944 実は、RWS こと「RESTful Web サービス」、昨日入手したところでした。セレンディピティ*1、ですね。早速開いてみています。 RESTful な任意矩形指定 RWSこと「RESTful WEb サービス」5章 p.124 に、次のように書かれています。 http://maps.example.com/geologic/Earth/43.9,-103.46 この
1点からの半径検索は、Google 投影に変換してから検索するのがベストプラクティス？ -- 第1回: Google 投影にふれる -- - Relevant, Timely, and Accurate
1点からの半径検索は、データを単純なメルカトル投影 (例えばいわゆる Google 投影)に投影しておいて、検索点を検索距離だけ高緯度にずらした所の縮尺係数を掛けた矩形を使って検索をするのも手。 というような主張を、何回かのエントリに分けて行っていきたいと思っています。今回は、「いわゆる Google 投影」を導入します。 きっかけ ここギコさんのエントリ： latlongをUTM（ユニバーサル横メルカトル図法。m単位の直角座標系）に変更し、その上でdistance関数を使って範囲検索を行っていました。 http://kokogiko.net/m/archives/002135.html 問題があるとすれば、UTMは経緯度範囲で適用する座標系が異なるので、複数の座標系をまたがるような範囲に対してサービス提供するアプリケーションの場合、その範囲の座標系毎に関数インデックスを張っておかないとい
JRuby は確かに速い。（というか、私の場合は -O -J-server を知らなかった...。） - Relevant, Timely, and Accurate
JRubyが遅いという話は過去のものになるかもしれません。 http://recompile.net/2007/10/trunkjruby.html を拝見して、改めて私の用途についてベンチマークを取り直してみました。 ベンチマークの内容は、 99819 レコードある Shapefile ファイルを読み、読んだレコードをすべて別の Shapefile に書き出す。 というもので require 'geotools' src = '(...)/transl_1_1.shp' start_time = Time.now Geo::Writer.open('trans.shp') do |w| Geo::Reader.foreach(src) do |g, a| w.write(g, a) end end print "#{Time.now - start_time}s\n" というものです。g
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
