地図表示範囲ないの不動産物件を表示するマプレットを作成してみました。
物件情報には、スマッチさんのAPIを使わせてもらっています。
Mappletの場所はこちらです。
http://convivial-web.com/mapplets/smatch.xml
登録方法はこちらに丁寧な解説がありました。
■Mapplet作った@速報ダム日和
Google MappletとGoogle Maps APIは、ほとんど同じといっても、
使えないクラスがあったり、GetCenterがGetCenterAsyncになっていたり、
微妙に異なる点があります。
使用できるクラス等のリファレンスは、こちらにまとまっていました。
Google Mapplets Reference
さらにopenInfoWindowHtmlで設定したHTMLがちゃんと反映されないぁと思っていたら、
こんな一覧もちゃんと用意されていました。
Content Allowed in Mapplet Info Windows
2007/6/6追記
たたみラボさんに紹介されました。
ありがとうございました。
一箇所にたくさん物件が存在するときにエラーになってしまったり、
まだ不具合だらけなので、時間をみつけて修正します。
カテゴリー: geo (5ページ目 (6ページ中))
GoogleMapsの新しいサービス「Street View」が大変な話題になっていますが、なんか例のあれみたいですね？
というのは置いておいて、今回の本命は「Mapplets」です。
これって、ここギコさんの予言していたそのものですよね。
今までいくつかマッシュアップを作ってきましたが、全部Mappletで置き換えてしまえそうです。
と思ってさっそく試してみているのですが、どうやらGTileLayerが使えないようです。
なので、ラスタ重ね合わせとかはちょっと無理っぽいのです。
GMarkerは使えそうなので、とりあえずスマッチWebサービスあたりから実装してみようと思います。
GoogleMapsを使ったマッシュアップというと、
ポイントデータを地図上に並べたものが大半かと思います。
ラインやポリゴンも一応は扱えますが、大量の図形を描画するのは難しいのが現状です。
そういった場合でも、ラスタ画像にしてしまえば、ちょっと気の利いた表現ができるようになります。
イギリスのサイトですが、不動産価格をラスタ画像にしてマッシュアップしています。
Sold House Prices in England
不動産の価格が高いところほど、地図上が赤く表示されます。
地図を拡大していくと、個別の不動産物件情報も表示できるようになっています。
単純に不動産価格を集計しているようですが、HEXで集計しているところはおもしろと思います。
もうひとつ、これもイギリスのサイトです。
Property hot spots – map of average house prices
こちらは地区ごとのポリゴンを、不動産価格で色分け表示しています。
この色分けレイヤは、GoogleMapsの上に半透明で表示されているのですが、
その透過率をユーザーが変更できるようになっています。
GoogleMapsの地図は、場所や縮尺によって色合いがバラついているので、
このようなインタフェースを設けているのだと思われます。
日本でも、スマッチWebサービスや、公示価格情報を使って、似たようなものが作れそうです。
急にMapServerのパフォーマンスが気になりだしてしまったので、
ちょっと調べていたら、同じような記事を見つけました。
MapServerとArcIMSの比較
ArcIMSは仕事でもいぢくったことがあるんだけど、なかなか性能の良いエンジンだった。それと同等？もしくは以上の性能が立証された？？？
DM SolutionのオフィシャルページにはArcIMS以上の性能と宣言されていました。
Performance
MapServer has been proven to be as efficient, if not more efficient than industry standard commercial software. Several comparisons have been done with ESRI ArcIMS demonstrating comparable if not faster map rendering speeds.
以下の記事では、ArcIMSとMapServerを競争させています。
ArcIMS vs. MapServer – Some Hard Data
MapServer
Total time: 7.47 min (467 sec 0.1566 sec/map (image), 385 maps/min)
Max delay for a map: 2.93 sec
Min delay for a map: 0.14 sec
Average for a map (with six simultaneous clients): 0.96 sec
ArcIMS
Total time: 12.08 min (728 sec 0.2426 sec/map (image), 247 maps/min)
Max delay for a map: 3.94sec
Min delay for a map: 0.12 sec
Average for a map (with six simultaneous clients): 1.49 sec
Windwos2000Serverで、200MBのShapeベクトルデータを読み込ませたところ、
MapServerの方が良い結果が出たようです。
これだけですべてを判断できるわけがなく、
・もっとたくさんの同時接続があるときは？
・RDBと連携したときは？
・ラスタデータの場合は？
など、いろいろと気になることはありますが…
MapServerのメーリングリストの中にこんな投稿がありました。
“Advantages of ArcIMS
– distribute applications over multiple machines
– Native integration with the Geography Network. MapServer can be
made to work within the geography network.
– Includes software to handle routine tasks like making the map
services (map files), designing web sites, etc.
– Supports more data formats – especially raster
– Better support for storing spatial data in RDBMS through SDE
– You don’t have to try to sell a relatively unknown product
(MapServer) and philosophy (Open Source)
“Disadvantages of ArcIMS
– speed (even running mapserv as regular cgi it is much faster)
– resource hog
– limited OS (no Linux)
– less stable. My ArcIMS experience is on NT so that may be more a
reflection of the OS than ArcIMS.
– poorer support
– source code unavailable
– cost”
結局のところ、速さだけならMapServerの方が上のようです。
ちょっと強引ですが、「OracleよりもPostgreSQLのほうが速い」、みたいな感じでしょうか。
PSPといっても、Play Station Portableではありません。
Push-pin Service Providesの略で、オークニーの森さんが作った言葉です。
Where2.0雑感
●マッシュアップサービス系
PSP(Push-pin Service Provides；勝手に命名）
何社もの新興のPSP達が積極的に宣伝をしていた。彼らはGoogleの公開APIを使
ったり、独自のものを開発したりしている、要するに”なんちゃってGoogle Maps”だ。アメリカでは本当に気軽にビジネスを始めてしまうんだなぁ．．．
ほとんどの会社がここ数ヶ月内に始めたばかりで、ビジネスモデルが見えないので私には彼らが成功するようには思えない。
上記のエントリは8ヶ月ほど前に書かれたものですが、最近日本ではクネヒトという会社がこんなプレスリリースを出しました。
クネヒトとチューリッヒ：業務提携発表と共同サービス・ローンチ
本日、クネヒトとチューリッヒは業務提携にもとづいて、共同サービスをローンチいたしました。
プレスリリース ： クネヒト、事件・事故の可視化サービス「Knecht ハザードマップ」をチューリッヒ保険会社に導入
22才の大学生が、資本金1円でやっているとのことで、すごいの一言に尽きます。
※余談ですが、ローンチという言葉を初めて知りました。
Web上で地図を扱う場合、(GoogleMapsのように)ベースとなる地図画像の上に、少量の図形を描画するという方法が一般的になってきています。
具体的にどうやって図形をブラウザ上に表示しているかというと、ブラウザの種類に応じて様々な方法が試みられています。Firefox2では、SVGをサポートしているため、ラインやポリゴンはSVGに変換されてHTMLの中に埋め込まれています。IEではVMLという独自のベクトル描画の仕組みが使用されています。他にもHTMLとCSSを駆使して簡単な図形を描画したり、サーバサイドで画像を生成したりと、様々なテクニックがちりばめられています。出来る限り多くのブラウザで、出来る限り快適に地図を見るための工夫が随所が見ることができます。
GoogleMapsの中では単に図形描画のために使われているSVGですが、国内ではSVG自体を地理情報の標準フォーマットとして扱おうということになってきているようです。
地理情報システムにも「2.0」の流れ、“国産Google Maps”が実現するか!?
Google Maps上でのコンテンツ表示方法は、従来のGISからすると「非常にプア」なものになる。それまで築いてきたGIS資産をGoogle Maps上で提供すると情報量が低下してしまうことがあるとし、「Google Mapsだけで使えるデータにするのではなく、オープンスタンダードを採用したデータに移行していくことが重要だ」と訴えた。
…
国が提供するSVG地図と“マッシュアップ”したgコンテンツの流通が促進されることを狙い、まずはSVG電子地図ビューアを広く普及させたい考えだ。
「SVG Toolkitの開発」が財団法人日本情報処理開発協会事業で採択
「SVG Toolkit」が想定するSVG電子地図表示ソフトウェアの動作形態は、現在デスクトップPC上でもっとも多く普及しているMicrosoft社製の Webブラウザ・ソフトウェアInternet Explorerのプラグインソフトウェアとして提供する予定です。また、Windows Vistaにも対応する予定です。
従来のGISと比べたら、GoogleMapsなんてしょぼ過ぎるので、なんとかして「大量のベクトルデータをオープンにWeb上で扱える仕組みを作りたい」ということなのでしょうか。SVG(XML)が交換・流通用フォーマットに適しているというのはよくわかります。
ですが、ブラウザでSVGを直接扱うというのはまた別の話です。
XMLをブラウザで直接扱うには、無駄が多く、あいまいな点が多いことがわかってきています。
無駄が多い点はJSONで解決され、あいまいな点は(GoogleMapAPIのような)ライブラリやフレームワークで吸収するという方法がとられています。
今回開発されるIEプラグインが、GoogleMaps並みにぐりぐり動いて、FirefoxのSVG対応等とも互換性を保ちつつ開発ができるようなものになってくれると大変うれしいです。
2007/3/5追記
ここギコさんの記事によると、開発中のSVGビューワは神速らしい！
前のエントリーでGoogleMapsAPIにポリゴンの描画機能が追加されたことを書きましたが、そのパフォーマンスがどの程度なのか、こんなページを作って調べてみました。
GPolylineと同じく、IEは「VML」、Firefoxは「SVG」を使って描画しているようです。(それ以外はPNG生成？)ですので、性能のほとんどはクライアント側のPCに依存していると思います。
自分のPC(Athlon64 3000+)では、100個くらいで地図描画がもたつく感じになりました。
どちらかというと、IEの方が少し軽いようです。
このようなお絵かきをブラウザ上で行うなんて、少し前までは考えられなかったのですが、今では
dojo、Walter Zorn、OpenLayersなどのライブラリ内で、似たような機能が実現されています。
そういえば、電子国土の非ActiveX版がSVG対応だという噂を聞いたような気がしたので、
見に行ってみたのですが、自分がインストールしているブラウザ(IE7とFirefox2.0)では、まったく見れませんでした。
しかも「Microsoft Windows」のみしか対応しないとは、いったい何のための非アクティブX対応なんでしょうか？
Google Maps APIにポリゴンの描画機能が追加されました。
これまでは、独自に描画する方法を作りこむ必要がありましたが、
ついに公式の機能へ追加されました。
大量に描画した際のパフォーマンスが気になりますが、
うまく使えば表現力を格段に高めることができます。
これでまた一歩、GoogleMapsがWebGISへ近づいたように思います。
Japanese Address and Placename Support Added to the
Google Maps APIのジオコーディングが、ついに日本の住所に対応しました。
商用利用ができないとはいえ、地図会社との関係で実現は難しかろうと言われていたので大変驚いています。
これはこれで大変うれしいニュースではあるのですが、
ますます位置情報開発がGoogleに染まってしまいそうな危機感もあります。
日本版ジオコーディングに関しては、Geocoder.jaもがんばって欲しいです。
最近のコメント