位置とは？

見合いパーティー　厳選について

見合いパーティーを厳選しました。見合いパーティーでうまくいくポイントや厳選見合いパーティーのご紹介のサイトです。見合いという言葉のイメージや、パーティーというと腰が引けてしますかもしれませんが、見合いパーティーとは、本当に気軽に参加ができて、しかもきちんと結婚相手を探すための出会いの場です。慣れないうちは、緊張感のほうが楽しみより大きいと思ってしまいますが、でもみんな出会いを求めて参加をしてます。待っていてはもったいないと思いませんか？そこで、見合いパーティーについての情報を掲載しましたので、見合いパーティーに参加する時にお役立てください。

このページは 2007年 03月 09日 01時36分41秒にクロールしたキャッシュ情報です。

検索キーワード＝見合い
優先キーワード＝

位置とは？

[ 25] Geo metadata - 位置に関するメタデータとその応用
[引用サイト]　 http://www.kanzaki.com/docs/sw/geoinfo.html

ウェブ上の様々なリソースは、「位置」に関する情報と組み合わせることで、リアルな世界と結びつきます。緯度経度データをRDFやmeta要素として提供したり、そのデータを地図上に表現するなど、位置に関するメタデータを記述する方法とその応用について検討してみます。
現実の世界の事象を記述するにあたっては、日時と並んで場所に関する情報が重要です。場所の表現には、住所表記、郵便番号、最寄り駅やランドマークなどさまざまな方法があり、状況によって使い分けられます。メタデータとして機械処理しやすく、グローバルな指標として一番確実な場所の表記法は、緯度・経度でしょう。
GPSや地図サービスの普及で、ある場所の緯度・経度情報は比較的簡単に入手できるようになってきました。これをウェブ上のリソースにメタデータとして付加すれば、さまざまな情報を現実世界に結びつけることが可能になります。たとえばレストラン情報、コンサートやイベント情報が位置データを備えていれば、催しに出かけたあとで食事をする場所を探すといった検索をエージェントに任せられそうです。写真に撮影場所のGPSデータが加われば、地図と連動した豊富な情報サービスが考えられます。
（地理情報を利用した応用は、GISを始め非常にたくさんの試みがあります。ここでは、RDFを中心としたメタデータによるものに絞って紹介します）
この語彙では、人間などにも位置情報を与えるためのSpatialThingクラスと、「地点」として緯度経度を与えるためのPointクラスが定義されており、位置との関連が曖昧なリソースと厳密な場所の両方に利用できるようになっています。
緯度。度分秒形式ではなく百分率を用い、北緯を正数、南緯を負数として記述する。
位置を示すのに緯度・経度を用いるというのは、誰でも考えつくアイデアです。逆にそれだけ使う機会も多いので、シンプルな標準語彙を共有するメリットは大きいと言えます。
人がどのあたりを拠点にしているかを示すFOAFのbased_nearプロパティは、この語彙を使って次のように表記できます。
このメタデータは、この人物が北緯35.678、東経139.770という地点の近くに出没するといった情報を示しているわけです。この例は、ノード要素（geo:Point）を省略して次のように簡単に書くこともできます。
Geo vocabularyを始めメタデータでは通常、緯度・経度を百分率で表記します。一方、世の中で入手できる位置情報は、度分秒形式になっていることが少なくありません。これらはごく簡単な計算式で相互変換できます。度分秒から百分率への換算は次のとおりです。
百分率から度分秒への換算はこの逆を行えばよいわけで、上記の例は北緯35度40分40.8秒、東経139度46分12秒を示すことになります。また、度分秒では東経/西経などはE/Wといった識別子を用いることが多いですが、百分率では西経/南緯はマイナスの値として表すことに注意してください。
空港はデータベースが整備されているので、その位置情報を調べるのは簡単であり、ICAOもしくはIATAの空港コードさえあれば、座標を具体的に指定しなくても理解可能というメリットもあります[AIRPORTLOC]。上の例では緯度・経度はgeo:を用いて示しましたが、Aiport語彙に含まれるair:latitudeなどを用いることもできます。また、これらの値はリテラルなので、Aiprot要素の属性として簡単に記述しても構いません。
このnearestAirportは、「近くの空港」という比較的アバウトな指標を使って位置を示すことで、住所を特定してしまうというプライバシーの懸念を回避しつつ、広域的なレベルでその人物がどのあたりにいるのかが分かるという点が興味深いところです。
緯度・経度データの小数点以下を何桁示しておくのがよいかは、データをどんなスケールで利用するかによって違ってきます。特定の場所にカーナビなどを使ってたどり着くためにはかなりの精度が必要である一方、世界地図の中でおよその位置をプロットするのであれば、低精度の値で十分です。また対象となるデータによっては、プライバシーとの兼ね合いも精度に関係するでしょう。
（場所の名前を示すlocationプロパティと緯度・経度のgeoプロパティが別々になっているのがイマイチなので、この辺りの構文は変更されるかも知れません）
イベント情報に緯度・経度を結びつければ、カレンダーをクリックするとその場所の地図が表示されるといった応用が簡単に実現します。例：
シュトゥットガルト放送響2004来日公演カレンダー、およびRDFMapperによる地図生成のテスト（ブラウザによっては文字化けの可能性あり）
今のところRDFベースではありませんが、緯度・経度情報に基づいて世界のホームページを収集しているデータベースが[GeoURL]です。自分のサイトをGeoURLに登録するには、まず次のようなmetaタグをホームページのhead要素内に記述します。
これらのタグを記述してアップロードした上で、GeoURLのページからリクエストPINGを送ると、指定URLのタグをチェックしてデータベースに加えてくれます。
（GeoURLの地図インターフェイスの縮小版。地図上の赤点は、ある1日に登録されたサイト）
データベースからは、地図をクリックしたり、北緯35.678度・東経139.770度から半径100マイルにあるホームページ、あるいは自分のURLの近所にあるサイトといった具合に指定して、「ご近所さん」を見つけることができるようになっています。
デジタル写真の撮影データなどを記録するExifフォーマットには、GPSの緯度経度情報などのためのディレクトリ・タグも定義されています。GPS付きの携帯電話カメラも登場しており、写真に位置情報を追加するのはずいぶん身近になってきました。これを利用すると、地図と写真を組み合わせたサービスなどが簡単に提供できます。
デジタル写真からExifデータをRDFとして抽出すれば、例えばXSLTを使って簡単に地図サービスへのリンクなどを加えることができます。
携帯電話デジカメ/メールによるウェブログ（moblog）のサービスにはGPSデータを扱う機能を備えたものがあるようですし、これらを地図上に表示したりする試みもいくつか登場しています。これらの多くはRSSを提供しているので、緯度・経度情報をgeo:で表現してここに含めてくれると（例えば次のように）面白いのですが。
位置データとデジタル画像とRSSを組み合わせて地図連動型アルバムをつくる実験を行っています（ここでは[Blogmapper]も利用しています）。また、画像のメタデータ表現については、以下のページも参照してください。
2つの地点の緯度と経度が分かれば、2点間の直線距離を算出することができます。GeoURLの「ご近所さん」は、緯度・経度情報をもつメタデータを集積し、「近くにあるリソース」を見つける好例です。イベントカレンダーで好みの演奏会を探し、そこから近隣のレストラン情報をリストアップするといった応用が考えられます。
//簡単な距離計算を行ってみましょう。次のフォームでは、2つの地点の距離を球面三角法を用いて計算します。緯度・経度データは百分率で与えてください。");
（スクリプトが有効な環境では2地点の緯度・経度から距離を試算するフォームが表示されます）
「半径何m以内にあるレストラン」という形ではなく、「東西、南北それぞれ○kmの升目に含まれるもの」といった方法でよければ、より単純な緯度経度データの比較だけでリソースを検索することができます。緯度の0.01度（36秒）はおよそ1.11km、経度の0.01度（36秒）はおよそ0.91kmに相当することを利用して、必要な範囲の緯度・経度の最小・最大値を計算し、その範囲に収まるものをピックアップすればよいわけです。
実際には、近くのレストランに行くのに直線コースをたどれる訳ではないうえ、交通手段の有無にも左右されるので、緯度・経度だけによる「近くのレストラン」というのは単純に過ぎるかも知れません。それでも、候補を絞り込む手段としては十分役に立つでしょう。
アプリケーションがメタデータから距離を計算するだけでなく、距離そのものをプロパティとして直接リソースどうしを関連づけることも可能です。foaf:based_nearなどはまさに「近い」という関係を示すわけですが、どの程度近い（遠い）かを何段階かの遠近レベルで表現できると便利かも知れません。
最初の3レベルは、地理的というよりもエドワード・ホールのプロクセミックスに一致する感じで、興味深いです[HALL]。この尺度がどのていど感覚にマッチするか、いろいろ捉え方はあると思いますが、距離を数値化するだけでなく、こうした「レベル」として見るというのはなかなか面白い考え方だと思います。
ある地点までの行き易さは、直線距離よりも交通手段などによって左右されるので、厳密な距離よりもこうしたおおまかなレベルの方がかえって適切かも知れません。例えば、あるホテルの近くにあるレストランをリストアップする際、歩いていけるA店（3^6=約700m圏内）、地下鉄で一駅程度のB店（3^7=約2.2km圏内）、などといった形で示すことができます（wn:はRDF版WordNetの名前空間とします）。
GeoOnionのプロパティは、2点のうちいずれかの緯度・経度があまりはっきりしない（させる必要がない）時などにも使えます。foaf:based_nearで自宅の緯度・経度をピンポイントで示したくはないでしょうから、近くのランドマークの緯度・経度を使い、そこが自宅からどの程度の範囲にあるかを表しておくという方法です。自宅から6.5km程度以内の地点を使ってbased_nearを表現するなら、次のような具合になります。
現時点での実用性のほどはともかく、感覚的な尺度に近いものをメータデータ記述の語彙に取り込むという考え方は、いろいろ可能性がありそうです。
ある地点の緯度・経度値は本来唯一に定まるはずですが、実は基準の取り方によって異なる値が併存するというややこしい事態になっています。日本では、従来は明治以来の測量基準によって緯度・経度を求めてきましたが、2002年4月1日に新しい測量法が施行され、人工衛星や電波望遠鏡に基づく世界基準に移行しました[G2000]。一般に前者を日本測地系（Tokyo Datum）、後者を世界測地系（WGS84）と呼んでいます（※注）。
GPSやGISの利用が進む中、グローバルに同じ尺度を用いる世界測地系への移行は必然的ですが、2003年末現在ではまだ日本測地系に基づく地図もまだたくさん使われており、2つの測地系が混在している状況です（オンライン地図サービスの多くは日本測地系です）。両者の座標は、東京付近で約450mずれていて、具体的な場所を記述するためには、ちょっと大きすぎる誤差となっています。
緯度・経度情報を取得する際は、その測地系も合わせて確認しておくことが重要です。また、メタデータを記述する場合は、（もしデータが日本測地系なら）世界測地系に変換すること、メタデータを利用してオンライン地図サービスなどと連動させる場合は、地図の測地系をチェックすることも忘れないでください。
日本測地系と世界測地系の座標は、幾何学的な計算で相互に変換が可能です。以下のフォームでは、Javascriptによる変換を試してみることができます（厳密には、基準点のひずみの補正が必要です。より精度の高い変換のためには、国土地理院から提供されているツール[TKY2JGD]などを利用してください）。
//このフォームでは、緯度・経度の測地系変換または度分秒<->百分率変換を行います。データは百分率でも度分秒でも構いませんが、度分秒の場合は35/40/40.80という形でそれぞれの値を'/'で区切ってください。変換結果は、入力フィールドのデータを置き換えて表示します。");