今年もFOSS4Gが開催される。
関西では奈良大学で開催予定↓。
奈良大学はESRIのイベントとかでも使われるし、GISの教育にすごく力を入れてる。
FOSS4Gでも学生さんが発表してるのを見たことがある。
ハンズオンの内容が未定ですが、
オープンソースGISのハンズオン研修が受けられるごくわずか機会なので、
この2日間はできるだけ予定空けとこうと思う。
講師が外国人だったりするのも脳みその普段使ってない部分を使えるいい機会だったりする。
今年もFOSS4Gが開催される。
関西では奈良大学で開催予定↓。
奈良大学はESRIのイベントとかでも使われるし、GISの教育にすごく力を入れてる。
FOSS4Gでも学生さんが発表してるのを見たことがある。
ハンズオンの内容が未定ですが、
オープンソースGISのハンズオン研修が受けられるごくわずか機会なので、
この2日間はできるだけ予定空けとこうと思う。
講師が外国人だったりするのも脳みその普段使ってない部分を使えるいい機会だったりする。
先週買ったデジカメをベルトにマウントするためのグッズ。
カメラ用 ウエストベルトマウント ボタンバックルハンガー デジタル一眼レフカメラウエストバンドベルトストラップマウント用 + レンズキャップホルダー
意外と横幅がかさばったのと、強度的に不安な感じですが、
100均で買ったマジックテープとカラビナを使って、ちょっと工夫してみました。
黒いパーツは本来ベルトなどに通して腰に一眼デジカメをつりさげるためのものですが、今回はこれをつかってリュックの肩ひもにカメラを固定したいと思います。
↑100均のカラビナについてた2重リングでマウント用の丸い突起ついた球体関節みたいなパーツとカメラ本体を接続してます。
↓丸い突起部分を黒いパーツの溝の上のほうからカチッと音がするまで下げるとセット完了です。
↓黒いパーツはこれまた100均で買ったマジックテープのベルクロでリュックの肩ひもに固定。
幸い肩ひものの材質もマジックテープに良くくっつくのでそれほどきつく締めなくてもしっかり固定できました。
これでGPS付きデジカメの使い勝手と精度が上がるといいんですが。
データベースの勉強してます。
データが増えるとファイルで管理するよりデータベースで管理するほうが云々、てことが↓の本に書いてあって、会議録なんかもWordで各人がペチペチ打って管理するより、ほんとは集中管理するほうがいんだろうなと思ってた。
この本、会話形式で初心者向けですが、Filemakerにとびつく私のような初心者に抜けがちなデータベースの基本概念が書いてあって勉強になります。
Filemakerにはフィールドの桁数が設定がなくて、長いテキストもほりこめる。ってことで現在会議録を作ってるところ。
役所は紙で回覧するので、印刷がうまくできないと困りもの。
A4で印刷することを想定して、また長い議事録の場合も想定してあらかじめ数ページ分の縦に長いフィールド枠を設定してます。
ただ、そのままだたとフィールド枠より実際の議事録は短い場合が多いので、印刷すると何もないページが多くて無駄が多い。
そこで、Filemakerのスライド機能を使うと、テキストフィールドの空行を自動的に詰めてくれる。
入力用のレイアウトと印刷用のレイアウトを分けて設定して、印刷用レイアウトには上記のとおりフィールド枠を縦に長い複数ページにまたがるようにして、かつスライド設定しておく。
印刷するときは自動的に印刷用レイアウトに移ってから印刷するように短いスクリプトを書いて、「印刷ボタン」にスクリプトを設定する。
大体できたんですが、あと資料登録・取出しのスクリプトをつくり中。
Filemaker、独学だと進捗悪いし、どう学べばいいかわからんかったけど、一つは人に教えてもらうのが手っ取り早かった。もっと早く気づけばよかった。
とはいうものの、お金はかかるので、WEBセミナーも一つの手です。公式のものもあれば↓、Youtubeでもあります。
金曜は仕事があったので2日目の土曜しか行けませんでしたが、
初めてオープンソースカンファレンス京都2016に行ってきました。
受付はあったけど、別に事前申し込みのチェックをするわけでもなく、配布資料をくれました。受付のお姉さんがかわいかった。
受付には初心者用の首から下げる名札があって、「つけたかったらつけてもいいよ」って感じで置いてありました。初心者名札つけたら、こんなおっさんでも誰か親切にしてくれたんだろうか。
↓展示会場の様子(ここ以外にも展示会場はありましたけど写真撮ってない)
ブースを見てまわると、企業やユーザー会に交じって、コミケ的な感じ(本物を行ったことないのですが,,,)出展もあって、同人誌みたいな冊子(中身見てない)を販売してるところもありました。嫌いじゃないけどおっさんだし恥ずかしくて素通りさせていただきました。
で、展示会場とは別の会議室ではいろんな発表がありましたが、どれも表題でイメージしてたのと内容が自分的には違いすぎて、ついていけないのが多かった。ただ、そういう世界で仕事なり活動されてる方が大勢いて、一口にオープンソースといってもいろんな切り口があることを改めて痛感。
仮想化の話とかサーバ・インフラの運用・管理・監査の情報が多かったような気がします。DockerとかOpenStackとかなんとなくしかわからない話がここでは基礎知識のような感じです。
その中で高橋基信さんのSambaの話と中小企業現役IT担当者のSugachanの話が面白かったです。恥ずかしくて「サインして」が言えませんでしたが、高橋さんのブースで本買いました↓。
【改訂新版】サーバ構築の実例がわかるSamba[実践]入門 (Software Design plus)
Sugachanの話は業務改善に取り組む人・組織にはうなづくところも多いかと思います。改善効果がみんなに役立つことが想像できないと、改善自体が受け入れられないという、人間の意識を変えるのは下からじゃ無理なんじゃないかと痛感させられた事例発表でした。だからこそ社内の風通しとか経営層のマネジメントがほんとに大事な気がする。役所もそうなんだよな~と思いながら聞いてました。スライド公開してくれないかな...
行ったからといって何かが変わるとは限らないけど、行くと何かは手元に残る。
また機会があれば行きたいです。
↓駅から会場までの道路(帰りに撮影)
やっぱり京都、ラーメン屋が多い気がする。会場近くの「ラーメン日本一」が量が多くて、大食いの人にはオススメ。
この手の機械は精度がどうこう言える代物でないことはわかってますが、
比較してみました。
比較対象はGarmin GPSMAP64(コンパスないやつ)
↓で赤星と赤ラインがTG-4。青点・青ラインがGarmin。
やっぱりGarminと比較するとTG-4は取得間隔が広い。
それとかなり揺れてる。
現実のルートはGarminのほうが忠実に再現してる感じ。あくまで比較の問題ですが。
Garminだって行きと帰りがルートが重ならないところは多々ある。
衛星の観測結果が大気の状態で揺らいだりすることを考えればこんなもんでしょ?
むしろよくやってると思う。
で、こういう代物をどう検査すんのかな?
ちなみに今回の観測場所はこんな感じのところ↓。
まあ、地形が急で衛星配置悪いだろうし、マルチパスの嵐でしょう。
林冠も結構閉塞してるし。
TG-4の改善点としては、電池の持ちを挙げたいと思います。
何でオリンパスは電池を大きくしないんだろう。
朝から撮りまくってると途中で電池がなくなって交換を余儀なくされる。
GPSロガーの取得間隔が長いのも電池の持ちが原因じゃないかと思う。
多少大きくなってもエネループを使えたらもっとイメージだけじゃなくてほんとに「タフ」になると思う。
それと、ポケットやザックにしまう使い方はGPSロガーの精度が落ちるので、
できるだけ体の高い位置(肩とか)に装着できるような固定方法があるといいと思う。ワンタッチで着脱できるようなのがあるとフィールドでの用途ですごく便利に使えると思う。
もっというとGarminときちんとカメラメーカーが組んでくれたら多少大振りでもいいのができないものかと思ったりしてます。
GIS勉強会で使う2.8.9を参加者に「それぞれインストールしといて」ってお願いしたばかりですが、今日QGISのサイト↓見たらLTRが2.14系になってた。
勉強会はテキストがQGIS入門(第2版)なので、2.8系でやるけど。
過去のバージョンのタイムスタンプ見たら2.8.3が2015年1月だった。
2.8.0がいつ出たのかはっきり覚えてないけど、Ubuntuなんか(Ubuntuの場合は「LTS」)は5年くらいサポートがある気がするけど、2年くらいでサポートがなくなるのはちょっと短いと思う。次のLTRの移行時期はどこかに情報があったのかもしれませんが、もう少しはっきり明示していただくほうが現場の混乱は少ないように思う。
開発が早くて便利な機能が次々盛り込まれるのはありがたいのですが...
年度末からFilemakerでぽちぽちと作ってた文書管理データベース。
文書だけでなく、「あの写真どこ行った?」とか「国からの通知文ってないの?」っていうのに対応した、ナレッジベースみたいな感じにしたくていろいろ試行錯誤してた。
苦労したのは、
1.通常状態での編集のロック。
2.取り込んだ文書ファイルを外部保存するのにFilemakerに自動でフォルダ作成をさせるところ。
3.調査ものを、自分の課への依頼→市町村等への外部へ照会→外部からの回答→外部からの回答をとりまとめして依頼元へ回答、といった流れでデータを管理・格納する器づくり
自分じゃどうにもならなかったのは1.ですが、一番時間かかったのは3.だったりする。仕事の流れに即したものになってるかどうかは使いながら検証するしかない。
3.の対応をするのにあたって文書データを格納するオブジェクトフィールドをかなりたくさん作ってしまって、文書管理用のデータベースとしては容量の増大が心配だったので、Filemakerの外部保存の機能を使いました。
デフォルトだと、違うレコードでも同じ名前のオブジェクトフィールドに同じ名前のファイルを保存すると後から入れたデータが保存されてない(上書きもされない)ことが分かって、2.のとおり、レコードIDを付与した保存先フォルダ名を新規作成させて、その中に保存させることにしました。
レコードIDは自動採番なので、同じデータベース内で一意になるので、それをフォルダ名に使えば、ファイル名が同じであってもきちんと保存することができます。
Filemakerは何でもできるわけではないんでしょうが、用意された機能をパズルのように組み合わせて比較的短時間で試行錯誤できる便利なソフトです。
しかし、素人くさいレイアウトを何とかすることができないか?
センスのなさはどうしようもないか...
170514追記
コメントいただいてアップしてないことに気が付いたんで、アップしました。
https://drive.google.com/folderview?id=0B46I9_ffr-QbS2tPUUszQ0ZlNXc&usp=sharing
ご確認ください。
で、外部にデータ保存するときのですが、
保存先のフォルダ設定はデフォルトだと↓こうなりますが、
↓こんなふうに変更してます。
考え方としては↓こんな感じです。
オリンパスのGPSデジカメ、TG-4を職場で買った。
ロガー機能でできたLOGファイル、NMEAデータとのことでしたが、
かなり情報が端折られてる感じがする。
自分的には衛星ナンバーが記録されてないのが非常に残念。
ロガー機能はSDカードが入ってないとONにできない。
まあSDカード入れないで使うことはないわけですが、
その割に自動でログがSDカードに入っていくわけではなく、
カメラの設定でSDカードへの書き込み操作をしないといけない。
まあそのへんはあまり気にしないようにして、
GPS機能がどんなもんか検証していきたい。
とりあえずロガーとして通勤ルートで使ってみた。
とったデータはカメラで確認できないので、
QGISに入れてみた。
↓マップビューにLOGファイルをドラッグアンドドロップ。
するとダイアログが開くので、トラックとポイントの両方選択してみる。
↓自動的に読み込まれて軌跡とポイントが表示されました。
ラインには大した情報はくっついたませんでしたが、
ポイントデータには取得時間が記録されてました。時刻はUTCみたい。
ポイントデータの取得間隔がちょっと長いような気もしますが、
実際何秒かよくわからないのと、自分で設定できないのがどうにも残念です。
次は林内でどんだけ使えるかやってみたい。
FileMaker初心者なりの工夫の話。
初期状態ではロックされた状態で、新規レコードや複製レコードを作らないと入力できない、っていう機能をやりたかった。
どうも複数のレイアウトを使うとこでできるらしい。
FileMakerはデータをいろんなレイアウト(アクセスでいうところのフォーム?)画面を作って、そこで表示させて入力や検索を行う。
初心者的にはレイアウトを作りながらテーブルを定義していけるところが敷居が低くていいわけです。
当然、ちゃんとしたデータベース作るなら思い付きじゃなくてちゃんと正規化してリレーションも組んでやるのがいいわけですが、
それはちゃんとデータベースの設計を詰めれるようになったらできることで、
ちょっとした自分用のデータベースを作る分にはそんなに厳密にやんなくてもいいと思ってた。
どう使いたいかさえ頭に入ってたら、それをすばやく具体化するのにいいツールだと思います。
いままで、レコードの複製を忘れて元のレコードをいじっちゃって壊してしまうことが多々あって、
初心者向けの掲示板とか漁ってみたこともあったけど、
自分のレベルで理解できる言葉で書いてあった試しがない。
以上、前置き。
上記の機能を実現する手順としては、
こうすることで、新規レコードや元のレコードを複製しない限りは編集できず、
過去のレコードを知らず知らずに上書きしてしまう事故がかなり防げると思う。
スッキリした。
Filemakerの講習でdbfファイルの読み書きができることを教わった。
そういうのはソフトウェアの仕様なので、調べればわかるはずですが、知らなかった自分。
いくつか注意点はありますが、
Filemaker13で読み込んだdbfを再度dbf形式でエクスポートしてみて、
QGISで読み込んでみた。
エクスポート時に文字コードをSHIFT-JISを選択するとフィールド名が文字化けせずに元の通りに出力できます。
致命的な問題は今のところない感じ。
文字コードが悪さしないといいのですが。
dbfの仕様で文字コードにunicodeを選べるのかどうか調べてみないとわかりません。
本家borlandのサイトではdbfの仕様がすぐに見つけられそうになかったので、
esriジャパンのサイトでshapeファイルの様書が公開されてるのでそれ見ても、
明確な記述はありませんでした。
http://www.esrij.com/cgi-bin/wp/wp-content/uploads/documents/shapefile_j.pdf
とはいうものの、DBFの文字コードをUTFに変更する手順がいろんなブログに書かれているので、
できないわけじゃないようです。
あまり複雑な手順を踏んでも日常業務のフローとしても問題あるので、Filemakerだけで済むとありがたい。
Filemakerを通すことで文字コードのほか、元のdbfにどんな影響があるかわかりませんが、
とりあえず様子見。
FileMakerのバージョン14はわかりませんが、出たばっかりの15の試用版を使ってみると、
このあたりの扱いは変わってない様子。相変わらず文字コードはASCIIとSHIFT-JISしか選べない。
とりあえず、自分としては致命的な問題がなければ、更新がやりやすいので、
Filemakerでいろいろできそうな気がする。