2010年12月23日木曜日

ISDNから光電話へ

1995年にISDNを導入したが、当時はまだインターネットが一般的でなくパソコン通信の時代でした。モデムでの通信では回線品質が悪く9600bpsが精いっぱいで、19200は無理だと言うことでISDNの導入に踏切ったのです。当時洋雑誌で情報を得て米国の通販店とのやり取りにFaxを使用していましたが、返事の来るのが深夜になることが多く、電話のベルを鳴らしたくないと、番号を追加して一つをFax専用にしていました。
その後インターネットが一般的になり、Faxもほとんど使わなくなったのですが、シェアウエアサポートなどでFax番号を公開していることもあり、そのままにしていました。最近はめったにFax受信することもなく、無駄だなぁと感じていたのですが、住んでいるマンションのひかり電話でNTT番号を引継げることになったので、切替えることにしました。ついでにFax番号も廃止です。これで電話とインターネットを合わせた月々の料金も1500円以上安くなります。切替え時にトラブルがなければ言うことなし。
正月明けてからの切替え工事で本日機器が届いたのだが、接続設定で不明な部分があります。添付の書類を見てもホームゲートウエイのWAN側の設定について何も記述がない。光回線のKDDIのウエッブサイトにも説明がない。ホームゲートウエイのATermのサイトにもない。ISPであるso-netのページでやっと、回線側は自動で設定されるという記述を見つけた。送付された接続IDとパスワードは何のためだ? まだ不安が残るが工事日に来る業者に確認するしかないな。 まるきり知識が無ければ気にしないのかも知れないが...

2010/01/09追記:
4日に切り替ったが、ホームゲートウエイのWAN側設定はユーザは触れないようになっていた。AirMacを経由するが、二重NATだと警告が出た。AirMacが黄色ランプのままなので警告にしたがいブリッジ設定にした。自分で触れないルーター任せにするのは少し不安なのだが。電話の切替えは1週間ほど後になるそうだ。

2010年12月13日月曜日

天地図(中国版地図サイト)

 「天地図」と言うサイトですが、Google Mapの中国版のようなものですね。すべて中国語(当然簡体字)なのがちょっとあれですが、何とか判ります。まだ試行版ということだからか、中国以外についてはデータも少ないし、拡大すると何も表示しなくなります。しかし中国内については地図そのものも、衛星写真も詳細に見られますね。ヒマラヤ山脈など衛星写真が詳細であることなどについて山関連のグループで話題になっているようです。
北京を少し見てみましたが、私が行った頃(30年程前)とは様変りで、滞在したホテルも見つけられませんでした。

2010年12月11日土曜日

北方四島の1/25000地形図

表題の地形図が今月一日に発売されました。1/5万の地形図は以前から発行されていましたが、内容は戦前のものに少し手を加えただけのものですね。今回の地形図は測量が平成22年となっています。ロシアからデータが提供されたとは思えないので、衛星から取得したデータで図化したものと思います。それにしても標高点が数多く記載されていますが、どのくらいの精度があるのでしょうね?
早速JMCからダウンロード購入したのですが、地図画像ビューアの索引図から読出すことができません。と言うわけで「地図画像ビューア3.2.3」を作成して索引図を表示したのが添付図です。発行されたのはこの13図葉だけですね。今後国後島の残りの部分や、択捉島も発行されるのでしょうか。

2010年11月27日土曜日

cocoa化計画

数値地図ビューアのバージョンアップが滞っています。SimpleDEMViewerは元々数値地図ビューアをバージョンアップするためのテストから始ったのですが、なかなか先へ進みません。そうこうするうちにcarbonの開発環境が貧弱なものになってしまい、今ではXcodeがまともにサポートしていません。またcarbonでは64bit化できません。
そんなこんなで、cocoa化せざるを得ないことになっています。すでに昨年からcocoaに手を染めており、基盤地図情報関係はすべてcocoaで64bit対応です。まずSimpleDEMViewerをcocoa化すべく着手したところなのですが、その一環として仕様を確認するために作成したプログラムが、今週実験室に公開した二つのプログラムです。ほぼ基本仕様が固まったので、具体的な作業に入りますが、今のSimpleDEMViewerのレベルで完成するのに半年近く、数値地図ビューアの次期バージョンとして公開できるのには1年前後或いはそれ以上かかるものと思います。技術的な内容とタイミングからして対応システムは10.6以降ということになりそうです。
さて焦らず急がずじっくり取組みますか。

2010年11月9日火曜日

ArcInfo ascii grid 標高データ

先日どこかで見つけてダウンロードした表題のファイルで、読込んで段彩図を表示できるのですが、アドレシングがうまくいかない物がありました。 cell サイズが整数なのでメートルで処理したのはいいのですが、UTMゾーンの中心経度から6度以上外れて経緯度との変換ができず標高値も表示できなくなります。ArcInfoを使用したことがないので判らないし、あちこちのウエッブサイトを見てもアドレシングについて明確な記述が見当りません。データを見ていると、国土地理院の19座標系のように適当な場所を原点としているような気がします。
現在のSimpleDEMViewerでは適当なUTMゾーン番号を指定しておいて、経緯度表示は無視してもらうしかないですね。標高値を表示できない場所は諦めていただくと(^_^;
現在データを読込むときにゾーン番号だけ聞いていますが、原点の場所も聞くか、単純にアドレス無しデータとして処理するか指定できるようにするかでしょうか。

2010年11月1日月曜日

基盤地図情報5m標高 鳥取・松江

本日表題のデータが公開されました。図はSimpleDEMViewerで松江部分を1/10サイズで描画したものです。湖沼データを作成していますが、中海の湖面標高が0.15mとなっているため、整数型で変換すると湖岸と同じになって正しく輪郭がとれません。「基盤地図標高変換」で32bit bil データに変換すれば図のようにすっきりした湖岸線が出せます。宍道湖の方は0.0mとなっているので整数型でも問題はありません。

2010年10月29日金曜日

ETOPO1 海底標高

海底標高を持っている世界の標高データは、以前はETOPO2(2分メッシュ)とETOPO5(5分メッシュ)が手軽でしたが、今はETOPO1(1分メッシュ)がメンテナンスされて最新版として維持されており、ETOPO2/ETOPO5はレガシー扱いですね。日本近海の海底地形も精度が上がっています。
ですが、NOAAのダウンロードページではどれを落してよいかよく判らない。またSimpleDEMViewerで使うにはbinで落して自分でhdrファイルを作成しなければいけないがよく判らん、という声がありましたのでここに使用法を記しておきます。

NOAAのダウンロードページへ行ったら、Download Whole-World Grids のところの binary をクリックします。図の赤枠のところです。ここで Ice Surface は南極とグリーンランドの標高は氷の表面で、Bedrock というのが地表の標高です。どちらでも以下の処理は同じです。grid-registeredとcell-regsisteredは1分ごとのメッシュの中央の値か、境界の値かの違いです。ここではcell-regsisteredを選択してください。
ダウンロードできるファイルのリストが表示されるので、etopo1_ice_c_i2.zipをクリックしてダウンロードします。i2が16bits整数、f4が32bits浮動小数点です。浮動小数点の精度は不要なので、データ量が少ない整数版にします。
ダウンロードしたファイルを解凍するとフォルダーの中にファイルが2個あります。.bin の方が標高データでこれのファイル拡張子を .bil に変更します。hdrファイルは仕様が異るので以下の内容に変更します。
BYTEORDER     I
NCOLS         21601
NROWS         10801
NBITS         16
ULXMAP        -180
ULYMAP        90
XDIM          0.016666666667
YDIM          -0.016666666667
以上でSimpleDEMViewerで読込めるようになります。図は100%サイズで作成した富士山中心の正射図法です。

2001/03/30訂正
NCOLSとNROWSの値を修正しました。
3/22付でデータが更新されていますが、16bitとtifが読めないですね。フォーマットが変わったのか、アップロード間違いなのか? 32bit float のデータだけは処理できますが。

2010年9月23日木曜日

10mメッシュ標高データの槍ケ岳


基盤地図情報の10mメッシュ標高データを利用して「XMapV」にて槍ケ岳の展望図を描くと図の上のようになります。どうしても槍の姿になりません。視点は北穂高岳にしてあります。
これは標高データがそうなっているからだというのを確認しました。図の中段は「基盤地図25000ビューア」にて長野県の等高線を1/2500表示したものです。これと展望図が完全に一致しているので、標高データはこの等高線に基づいて作成されているものと思われます。或いは別の基礎データから双方が作成されたのかも知れませんが。
この等高線を下段の1/25000地形図と比べてみるとおかしな点が浮かび上ります。地形図では一番高い等高線が3130mになっていて、それ以上の線は省略されています。ところが基盤地図情報では一番高い等高線を3180mとしており、線が足りないので、上から4番目の線の下に無理やり5本押込んだ結果が今の状態になっているようです。自動処理だけでここまでできるわけもないと思うので、人手が介入していると思うのですが、槍ケ岳の実際の形を確認しないで(知らないで?)、等高線を誤認したまま処理してしまったようですね。

2010年9月20日月曜日

core i3のマルチスレッド性能

先に書いたように、先月末に iMac core i3が到着したので、いろいろマルチスレッド性能を確認していました。 i3はcoreは2個ですが、ハイパースレッドが機能するので、3個の処理が同時に動けるからです。しかしハイパースレッドはインテル自身も30%かそこらの数字を言っているように単純に倍のcore数の性能が出るわけではありません。
私のプログラムでは数値地図ビューア、SimpleDEMViewer、基盤地図25000ビューアがマルチスレッドを利用します。前の二つでは展望図の作成、可視領域の描画時に大きく影響します。いろいろな設定で測定したところ、スレッド数3が最適なようです。4を指定するとcpuタイムでは400%近く行きますが、処理時間はほとんど変わりません。かえって遅くなることもあります。数値地図ビューアでは3を指定できないので4が最適ということになりますが、SimpleDEMViewerでは3を指定したほうがよさそうです。いずれもメモリが不足してページングが多発するような状況では、少なく指定したほうがいいでしょう。
core i5 や i7 ではどのくらいがいいのか試す環境がありませんが、core数までにしたほうがよいのかと思います。忙しいスレッドの数がcore数以下の場合はクロック数を上げるターボモードに入るらしいので、その方が結果的に速くなるでしょう。最適値がどのくらいかはそれぞれの環境で確認することをお勧めします。
基盤地図25000ビューアではファイル処理の部分だけなので、適当な値を自動的に設定しています。MacBook proやiMacではディスクの動作が遅いので、スレッド数を2より大きくしてもcpu利用率も増えず、ほとんど効果がありませんでした。Mac proでRaidでも使用していれば、効果があるのでしょうけれど。

2010年9月1日水曜日

XMapVで可視領域描画機能をサポート

本日公開した XMapV_100901 で可視領域描画機能をサポートしました。数値地図ビューアのものと同様の機能ですが、色を変えて重ね書きできること、基盤地図情報の10mメッシュ標高データが使えることが勝る点です。
図は日光・尾瀬近辺から富士山が見える地点(ピンクの領域)を描画したものです。標高データは50mメッシュです。遠隔地をチェックしようとすれば、たとえintelマックでも時間がかかるので覚悟してください。
開発中に数値地図ビューアのバグに気がついてしまいました(^_^;  視点の標高が指定されていても、標高データから計算された標高値を使用してしまいますね。したがって見えない場所が増えてしまいます。近距離の場合に影響が大きいようです。

2010年8月31日火曜日

iMac core i3 到着

本日new iMacが到着し、システムを入れ直して以前の環境と同じになるようにセットアップしました。で早速試したのがマルチスレッドの性能。core i3はハイパースレッドでそれぞれのcoreがスレッドを二つずつ流せるということで、4 core あるように振る舞うはずなのだが性能は? アクティビティモニターではcpu欄が4つ表示されます。
いつもながら展望図で試してみました。スレッド数を4にするとcpu使用率が397%くらいになります。確かに4スレッド流れていますね。それではと3にしてみたら、cpu使用率は306%くらいを示して妥当なのですが、終了までの経過時間がほとんど変わりません。え、何で? さらに2、1と減らして重い展望図の描画で次のような結果になりました。(数字は スレッド数/cpu使用率/終了までの経過時間)
4/396%/143"  3/307%/151"  2/204%/202"  1/102%/346"
スレッド数1と4で2.4倍の差しかありません。1と2で 1.7倍です。core duoや以前のG4ではスレッド数を2にすると1.9倍以上出ていたのでだいぶ成績が悪いです。処理自体は速くなっているので、オーバヘッドが相対的に増えたことによるのか、ハイパースレッドの性能がその程度なのか、対策可能かどうか検討が必要なようです。

2010年8月21日土曜日

展望図で残暑お見舞い

少し遅いですが、下旬になっても残暑が厳しいので、間に合いますね(^_^)
図は基盤地図情報の10mメッシュ標高データを用いた、立山の展望図です。視点は西南側の鍬崎山です。谷間には雲海機能を適用してあります。XMapV_100817を利用しました。
 コンソールにエラーメッセージを吐き出す件ですが、SimpleDEMViewerでも同じなので、対策をしないといけませんね。

2010年7月31日土曜日

基盤地図25000ビューアで標高データのサポート

地図中心の原稿にも予定として書きましたが、標高データのサポート作業中です。今日やっと陰影画像が描画できたところです。まだまだおかしなところがあるので、β版の公開にももう少し時間がかかりそうです。ただ今の方式だとだいぶ重いので、もしかしたらOpenGLに変えるかも知れません。そうすると公開はだいぶ先の話になってしまいます。
今のところ標高データは基盤地図情報の10mメッシュのみです。図は神奈川県の城山ダム湖付近。

追記:β1を公開しましたが、機能的には標高表示機能を加えて正式版とする予定。重いことには変わりないですが、OpenGLにはしないことにしました。

2010年6月29日火曜日

iMacの新型はまだか?

現在 iMac 17" と MacBookPro 13" の2台で運用している。
iMac 17" core duo 1.83GHz 1.5GB/150GB early 2006
MacBook pro core2 duo 2.53GHz 4GB/250GB mid 2009
iMacのディスクの空きがほとんどないのと、画面に縦縞が出てきてしまったのとで買い替える気になった。しかし現行のiMac も発表されてからだいぶ立ち、秋までには新型が出るのではないかと決断しかねている。縦縞が今以上に増えなければもう数ヶ月は我慢できるのだが(^_^;

基盤地図情報が出るまではディスク容量も問題なかったのだが、基盤地図情報を全部置こうとするととても足りない。MBPの250GBでも余裕は感じられない。ムービーはやらないし、写真もそれほど多くはないので、250GBで不安になるとは予想外だった。

追記:07/17
MacRumorsサイトに秋にMac ProとiMac が更新されそうだというrumorが出ていました。秋かぁ。

追記:07/30
発売されましたね。MacBook proのディスクのリプレースとメモリの追加と、外部モニタの利用とで1台で済まそうかと、少し悩んでますが、たぶん iMac 21.5" を購入するでしょう...

2010年6月16日水曜日

宇宙ステーションからの富士山


国際宇宙ステーションからニコンのカメラで撮影した富士山の画像があります。鮮明に写っていますね。北緯34.3度、東経142度、高度354kmからだそうです。XMapV_100113で作成した展望図が添付画像の左側ですが、だいぶ潰れて見えます。60度近い俯角で下を向いているので致し方ないのですが、この図のように狭い範囲の時は方法がないかと検討した結果、見下ろし角のcosで調整すればいいのだと判り、対策した結果がXMapV_100616による右側の画像です。広い範囲を描画したらひずむのは同じですが、今回のように画角(2度)が狭い場合は有効ですね。
なお数値地図ビューアの展望図は高度の最高が100kmなのでこれと同じ画像は作成できません。

2010年6月2日水曜日

Google社内でMS Windowsを禁止?

今朝の日経の英国発の記事だが、社内でMS Windowsを禁止する方向で動き出しているそうだ。マックやlinux はOK。主にセキュリティ面からだそうだが、自社のgoogle OSへ移行する布石との見方も。
自分はといえば、以前はだいぶ使っていたが最後に導入したのはMS Windows2000で、今はPoweMac G4(QS) 10.4(Tiger) 上のVirtual PC管理下で細々と動いているのみ。時々動作確認として動かしているが、外部(インターネット)とは接がない(接がらない)ので、セキュリティの面では問題なし(^_^) 数年前までは兄からMS Windowsに関して聞かれることもあったが、ここのところご無沙汰で、もう用済みか。
そういえば、自サイトで公開している機器構成が旧いままか。

2010年5月18日火曜日

プログラムのアイコン

 図は私が作成したプログラムのアイコンを並べた物です。古い物は除外していますが、SimpleDEMViewer以外は概ね日本列島を入れて統一性を持たせています。主要な四つ以外は比較的単純な図柄にしています。基本的に128x128ドットですが、SimpleDEMViewerのみ512x512ドットのアイコンを用意しています。これらのプログラムの中で、SimpleDEMViewer、データユティリティ、LSMixer、AscConvの四つは日本語、英語のマルチリンガルになっていて、データユティリティのみアイコンも変えています。
SimpleDEMViewerのアイコンは日本をもう少し中央に持ってきたかったのですが、太平洋が広くなりすぎてバランスが悪くなるので今の形になっています。中国が中央に来て少々シャクの種なんですが(^_^;

(訂正)ASCマークのアイコンはArcConvでなく AscConvです。

2010年5月3日月曜日

基盤地図情報の街区データ

基盤地図情報の街区データが5月1日から公開されています。早速基盤地図ビューアでサポートしました。大半のコードはすでに書いてあったのですが、データが無かったので外していました。あとは環境設定などのダイアログを追加修正するだけでしたので、二日で対応できました。
さて、図はさいたま市浦和駅付近ですが、左は建物、道路、標高点を除いて描画したもの。中は道路を追加したもの。右はさらに建物を追加しています。街区線は道路よりも先に描画しているのでほとんど隠れてしまいますね。街区番号は道路、建物より後から描画しています。街区番号というのは住居表示の地番のようですね。
プログラム添付の書類にも注意事項を入れましたが、街区データを読込む前に該当行政区域のデータをライブラリから読込んで(表示して)おかないと、ライブラリ中のデータが消えてしまうのでご注意を。

2010年4月19日月曜日

旧中山道を歩く

 今日の日経夕刊「あすへの話題」というコラムに表題の文章がありました。
定年後に歩いたそうです。自分の時と同様に何日か歩いたら家に戻って、次回続きを歩くという方法です。自分は20代だったので近場は土日、離れるとゴールデンウイークや3連休などを利用して1年以内で完了しましたが、5年をかけたそうです。今の私には歩けません(^_^;
今でも比較的旧道が残されているようです。日本地図センターのインタビュー記事でも触れましたが、旧東海道は国道バイパスや高速国道の整備でかなりずたずたになっています。今から歩くなら東海道よりも中山道ですね。東海道を歩いたときに、静岡の旅館で、数日前に日大の学生が袴に高下駄で歩いていったというのを聞いたが、今でもそういう強者はいるのだろうか。

4月19日は地図の日

 1800年(旧暦の)4月19日に蝦夷地まで第一次測量隊が出発したことにちなむそうだが、4月19日を「地図の日」と言い出したのはどこの誰か不明なようだ。日本記念日協会に登録されているわけでもないし、もちろん公的な決めはないだろう。

2010年4月3日土曜日

旧東海道鳥瞰図

先日サイトのアクセスログを見ていたら、「旧東海道+鳥瞰図」というキーワード検索で来ていたのを見つけたので、それではということで作成してみました(^_^)
標高データは250mメッシュです。50mを使用してもほとんど変わりません。高さは2倍強調にしてあります。今回はXMapV(SimpleDEMViewer改)を使用しましたが、数値地図ビューアでも同じ物を描画できます。旧東海道のデータは私のサイトで公開しているユーザ経路データです。

2010年3月30日火曜日

基盤地図情報と数値地図(地名・公共施設)

 今朝公開した基盤地図25000ビューア1.0a1でユーザメモデータを表示できるようにしましたが、図は「地名データ変換」で変換した注記を描画した物です。だいぶ地図らしくなりました。場所は拡大して見れば判りますが、赤城山です。
1.0a1ではメモの移動などもできないので、重なっているところなど残りますが、後処理で(Adobe Illustratorなどで)処理すれば何とかなりますね。SimpleDEMViewerと同様に移動や削除などはできるようにしますが、本格的に読みやすい地図にするには文字を斜めに配置したり縦書きにしたり、間隔を空けたり、背景を半透明にするなど色々な手が必要ですが、後処理に任せます。公共施設のマークはどうしましょうかね。

2010年3月9日火曜日

AirMac extremeは妨害電波に弱い?

昨秋購入した最新型のAirMac extremeですが、オレンジランプが点滅して再起動が必要な事態が先月から3回発生しました。初めの2回は電子レンジの動作中にiMacの電源を投入したときです。3回目は昨日ですが、電子レンジは使用してなく、iMacをスリープから目覚めさせたときでした。スリ=プから目覚めさせたときに接続を確立できないのは時々発生するのですが、iMac側でAirMacを一旦停止して再接続すれば普通は回復します。ところが昨日はペケ。このとき同時にFMラジオの電波が10秒ほど途切れていました。FMラジオの電波が途切れるのは其の前日にも発生しています。今まで無かったことなのですが、ちょうどマンションの工事中で何かの機械が動いていたようです。未確認ですが機械の不良で強力な電磁波を送出したのではないかと推定しています。
で3件の結果から、端末との接続確立時に強力な妨害電波があって、接続処理がうまくいかないときにAirMac extremeのファームウエアが混乱するのではないかと思います。確立している状態では電子レンジを動かしても速度が遅くなるだけで、接続が切れることはないのですが。
前の機種(円盤型)のときは電子レンジを動かすと接続が切れていたので、それよりはだいぶ改善されています。この時代は妨害電波に弱いことを意識していたので、電子レンジ動作中にiMacを起動するなんてことはしなかったので、現象が無かったのかも知れません。

2010年2月15日月曜日

基盤地図情報の精度?

 5mほどの位置ズレがあるとして一部のデータが公開停止になっています。しかしそれ以外にも疑問のあるデータがあります。
図は前橋市と高崎市の境界付近です。赤い線が市界ですが二重に見えます。道路などは問題なく接ながっているのですが、市界だけはずれています。オリジナルデータがどこから来た物か判りませんが、前橋市と高崎市の仲の悪さが影響しているのでしょうか(^_^; ここだけでなく、さいたま市と川越市の境界などでも発生していますけれど。それにしてもデータの精度が心配になる事態ですね。

2010年2月1日月曜日

数値地図(地名・公共施設)

今表題のデータをユーザメモデータに変換するユティリティを作成中です。とりあえずはSimpleDEMViewerで表示することになりますが、何れは「基盤地図25000数値地図ビューア」で表示できればと考えています。基盤地図情報(縮尺レベル25000)には行政界以外の名称が入っていないので、使い道が限られてしまいます。
作成中のプログラムは簡単にできるはずだったのですが、cocoaを勉強しながらガベッジコレクションその他の(小生にとっての新しい)テクニックを使い出したので、てこずってしまいました。今日やっと最上位データ区分をそのままメモデータの分類にした変換ができたところです。図はそれをSimpleDEMViewerで表示し、文字設定を少し調整した物です。
文字列の中にMS Windowsの外字が含まれており、「ヶ」など多いので、正しいユニコードに置き換えないと使いにくいですね。その辺も入れたいしで、まだしばらくかかりそうです。

訂正:「ヶ」は標準でありますね。「ガ」や「ノ」の小さな文字が外字対象ですね。図中の外字も「ガ」を小さくした文字です。文字毎にフォントサイズを変更するのはサポートしていないので、通常文字にするしかないか。

2010年1月23日土曜日

富士見日記


こちらのサイトで公開している富士見日記が13年目に入りました。富士山だけでなく丹沢と横浜のランドマークタワーも確認しています。富士山と、ランドマークタワーについて年間可視日数をグラフにしてみました。(右図) 2008年は年末にマンションの工事でランドマークタワーを確認できない期間が40日ほどあり、実際には15日程度多く見えていたと思いますが、大勢に影響はありません。

1998年を例外とすると富士山については漸減傾向に見えますが、ランドマークタワーについては2004年以前と以降ではっきり違っています。調べてみると2000年頃からジーゼル車の排ガス規制が強化され、2003/10からは粒子状物質規制を満たさない車は首都圏を走れなくなりました。当地からランドマークタワーまでは約20kmで、第一京浜、第二京浜国道が下を走っていて、この規制の影響が大きいと推定されます。環境規制の効果を実感できますね。

2010年1月17日日曜日

地震情報と経緯度

 地図画像ビューアとSimpleDEMViewerの最近のバージョンでペーストできる経緯度のフォーマットを拡充していますが、元はと言えば気象庁などの地震情報から震源の場所を確認したかったからなのです。気象庁の情報では右図のように漢字が入っています。またHinetの情報では2行に分かれています。USGSでは数字のみです。右の地震情報の経緯度を次の図のようにSimpleDEMViewerでetopo1を使って場所を確認します。ああ、海溝の西側の太平洋プレート内だな、とか相模プレートの下か、とか見ているわけです。内陸だったら地図画像ビューアで、地勢図で確認します。1件1件だけでなくメモデータを作れば群発地震の傾向も確認できます。(やっていませんが)
地震情報以外でもインターネット上ではいろいろな経緯度情報が様々なフォーマットで存在します。今のところ単純なテキスト形式だけですが、Google map 等のxml形式のデータもサポートすると便利ですね。

2010年1月12日火曜日

横書きフォント・縦書きフォント


MacOS Xの文字コードはユニコードが基本で、地図画像ビューア、SimpleDEMViewerなどもユニコードを用いています。ユニコードでは括弧や句読点など、縦書き用文字、横書き用文字があります。MacOS Xでは標準のAPIを用いて適切に設定すれば自動的に選択して描画してくれます。
XMapVの展望図で縦書きをサポートしていますが、括弧などは適切に描画します。しかし、データライブラリに置いた「ユーザメモデータ 日本の主な山」では括弧の一つとして <> を使用していますが、これは実際には括弧ではないので縦書き用文字がありません。そこで図の愛鷹山のようにおかしなことになってしまいます。複数の名称を持つ山の場合は 水晶岳(黒岳) と丸括弧にしているので問題ないが、 富士山<剣ヶ峯> のように総称とピーク名の場合とを区別したいので<>を使用したのが失敗でした。区別は残したいので、 富士山「剣ヶ峯」 とすれば図のようになるので、体裁が良くなります。データを修正しましょうかね。

2010年1月9日土曜日

World Boundary Databank IIで正距方位図法

 表題のデータを利用してすっきりした東京中心の正距方位図法を作成してみました。SimpleDEMViewerを利用しているので標高データが必須ですが、今回はETOPO2を利用しました。ETOPO5でもGTOPO30でも問題ないです。グラデーション無し、陰影無しに設定。海をグレーにしたが、真っ白でももちろんOK。
中心部で1/2千万。等距離円の間隔は500km。
World Boundary Databank IIのデータが今回の目的には細かすぎて操作がかなり重いですね。

重いのは、経路データをメインウインドウに描画するときに使用している高速化手法を、図法画像では組込み忘れていたためでした。修正します。(2010/01/19追記)
3.8.5として公開しました。ついでに512x512のアイコンを組み込んだので余計に大きくなってます。(2010/01/20追記)

2010年1月7日木曜日

AppleWorks

もう一昔前のAppleの「統合ソフト」ですが、後継を作成しないまま販売停止になってしまったので未だに使用しています。PPCオンリーなので、MacOS X 10.6(Snow leopard)では動作せず、今は iMac + 10.5(Leopard)で使用しています。iMacも4年たって画面に縦筋が出てきて、そろそろ替え時かと。それにつれて本格的にAppleWorksの置き換えが必要になります。ファイルは表計算、ワープロ、ドロ−です。ペイントその他は使っていません。
表計算は以前 iWorks の Numbers を試してみたのですが、どちらかというと表計算よりプレゼンテーションが(見栄えが)狙い目のようで、いまいち使い勝手が悪いです。したいことが簡単にできない。で、未だに変換できずにいます。
ワープロは以前EGWord等も使っていたのですが、こちらも販売/サポート停止。rtfでもできるかと試していたのですが、 iWorks の Pages が AppleWorks のワープロ書類をほぼそのまま読めることが判明。こちらは一安心。
ドロ−については先日 Apple のディスカッションサイトで EasyDraw がAppleWorks のドロ−書類を読み込めるぞ、とあったので試用版をダウンロードして試してみました。一応読めることは確認できたが、編集はまだ少し動かしてみた程度。追々結果を報告します。いにしえの SuperPaint のような使い勝手が欲しいのだが。

2010年1月6日水曜日

開設のご挨拶

初めてブログに挑戦することになりました。タイトルは「地図とマックと」ですが、小生のもう一つのサイトにも関連する、富士山や品川に関すること、日常生活に関すること何でも書込む予定です。元来が筆無精なのでどのくらいの頻度で書き込めるか判りませんが、月に1回以下なんてことにはならないようにしたいと思います。