位置に関するメタデータとその応用
ウェブ上の様々なリソースは、「位置」に関する情報と組み合わせることで、リアルな世界と結びつきます。緯度経度データをRDFやmeta要素として提供したり、そのデータを地図上に表現するなど、位置に関するメタデータを記述する方法とその応用について検討してみます。
This page is an introduction to RDF Geo vocabulary and its applications. Most parts are written in Japanese, but you'll find a short summary at the beginning of each section.
場所の表記とメタデータ
The location is very important data to describe real world things, along with date/time information. Latitudes and longitudes are ideal for location metadata, which could be related to photo-GPS or events, restaurants and others.
現実の世界の事象を記述するにあたっては、日時と並んで場所に関する情報が重要です。場所の表現には、住所表記、郵便番号、最寄り駅やランドマークなどさまざまな方法があり、状況によって使い分けられます。メタデータとして機械処理しやすく、グローバルな指標として一番確実な場所の表記法は、緯度・経度でしょう。
GPSや地図サービスの普及で、ある場所の緯度・経度情報は比較的簡単に入手できるようになってきました。これをウェブ上のリソースにメタデータとして付加すれば、さまざまな情報を現実世界に結びつけることが可能になります。たとえばレストラン情報、コンサートやイベント情報が位置データを備えていれば、催しに出かけたあとで食事をする場所を探すといった検索をエージェントに任せられそうです。写真に撮影場所のGPSデータが加われば、地図と連動した豊富な情報サービスが考えられます。
(地理情報を利用した応用は、GISを始め非常にたくさんの試みがあります。ここでは、RDFを中心としたメタデータによるものに絞って紹介します)
RDF-IGのGeo vocabulary
One of the most useful and handy vocabularies for location data is RDF Interest Group's Geo vocabulary.
緯度・経度といった位置データを記述するボキャブラリはいろいろありますが、RDFでメタデータを記述するために最も手軽で一般的なのは、W3CのRDF Interest GroupによるGeo vocabularyでしょう[GEOVOCAB]。
- 名前空間URI
http://www.w3.org/2003/01/geo/wgs84_pos#
- よく使われる接頭辞
geo:
Geo vocabularyのクラス
クラス | 内容 |
---|---|
SpatialThing | 場所、物体、人間など、空間的に存在してサイズや形、位置をもつもの |
Point | 緯度経度で示される地点。SpatialThingのサブクラス |
この語彙では、人間などにも位置情報を与えるためのSpatialThingクラスと、「地点」として緯度経度を与えるためのPointクラスが定義されており、位置との関連が曖昧なリソースと厳密な場所の両方に利用できるようになっています。
Geo vocabularyのプロパティ
プロパティ | 働き | domain | range |
---|---|---|---|
lat | 緯度。度分秒形式ではなく百分率を用い、北緯を正数、南緯を負数として記述する。 | SpatialThing | - |
long | 経度。百分率を用い、東経を正数、西経を負数として記述する。 | SpatialThing | - |
alt | 高度 | SpatialThing | - |
lat_long | カンマで区切った緯度・経度(削除予定) | - | - |
※プロパティの値はいずれも世界測地系で記述する。
位置を示すのに緯度・経度を用いるというのは、誰でも考えつくアイデアです。逆にそれだけ使う機会も多いので、シンプルな標準語彙を共有するメリットは大きいと言えます。
位置情報の利用例
FOAFのbased_near
The based_near property of FOAF is a good example to use the geo: vocabulary.
人がどのあたりを拠点にしているかを示すFOAFのbased_nearプロパティは、この語彙を使って次のように表記できます。
(例)
<foaf:Person> <foaf:name>Masahide Kanzaki</foaf:name> <foaf:based_near> <geo:Point
> <geo:lat
>35.678</geo:lat> <geo:long
>139.770</geo:long> </geo:Point> </foaf:based_near> </foaf:Person>
このメタデータは、この人物が北緯35.678、東経139.770という地点の近くに出没するといった情報を示しているわけです。この例は、ノード要素(geo:Point)を省略して次のように簡単に書くこともできます。
(例)
<foaf:based_near geo:lat
="35.678" geo:long
="139.770"/>
度分秒表記と百分率表記
The 'decimal' format of the latitude and longitude are better suited to metadata than 'dms' format. 'decimal fraction' = 'm' / 60 + 's' / 3600.
Geo vocabularyを始めメタデータでは通常、緯度・経度を百分率で表記します。一方、世の中で入手できる位置情報は、度分秒形式になっていることが少なくありません。これらはごく簡単な計算式で相互変換できます。度分秒から百分率への換算は次のとおりです。
[百分率の小数点以下] = [分] / 60 + [秒] / 3600
百分率から度分秒への換算はこの逆を行えばよいわけで、上記の例は北緯35度40分40.8秒、東経139度46分12秒を示すことになります。また、度分秒では東経/西経などはE/Wといった識別子を用いることが多いですが、百分率では西経/南緯はマイナスの値として表すことに注意してください。
nearestAirport
Another example is nearestAirport from 'contact:' vocab, together with DAML Airport vocab..
FOAFのbased_near同様の考えは、'contact:'と呼ばれる実験的なPIM用語彙に含まれるnearestAirportと、DAMLのAiport語彙を用いて、以前から試みられてきました[MILLER]。
(例)
<rdf:RDF xmlns:contact
="http://www.w3.org/2000/10/swap/pim/contact#" xmlns:air
="http://www.daml.org/2001/10/html/airport-ont#" xmlns:geo
="http://www.w3.org/2003/01/geo/wgs84_pos#" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:foaf="http://xmlns.com/foaf/0.1/"> <foaf:Person> <foaf:name>Masahide Kanzaki</foaf:name> ... <contact:nearestAirport
> <air:Airport
rdf:about="http://www.daml.org/cgi-bin/airport?HND"> <air:iataCode
>HND</air:iataCode
> <air:name
>Haneda, Tokyo International Airport, Japan</air:name
> <geo:lat
>35.55</geo:lat
> <geo:long
>139.78</geo:long
> </air:Airport
> </contact:nearestAirport
> </foaf:Person> </rdf:RDF>
空港はデータベースが整備されているので、その位置情報を調べるのは簡単であり、ICAOもしくはIATAの空港コードさえあれば、座標を具体的に指定しなくても理解可能というメリットもあります[AIRPORTLOC]。上の例では緯度・経度はgeo:
を用いて示しましたが、Aiport語彙に含まれるair:latitude
などを用いることもできます。また、これらの値はリテラルなので、Aiprot要素の属性として簡単に記述しても構いません。
(例)
<contact:nearestAirport
> <air:Airport air:icaoCode
="RJTT"air:iataCode
="HND"air:latitude
="35.55"air:longitude
="139.78"air:elevation
="35"> <air:name
>Haneda, Tokyo International Airport, Japan</air:name> </air:Airport> </contact:nearestAirport>
このnearestAirportは、「近くの空港」という比較的アバウトな指標を使って位置を示すことで、住所を特定してしまうというプライバシーの懸念を回避しつつ、広域的なレベルでその人物がどのあたりにいるのかが分かるという点が興味深いところです。
Jim Ley's FOAF People Map will show who's where in the world from their FOAF metadata.
Jim LeyのつくったFOAF People Mapは、収集したFOAFデータからnearestAirportを抜き出し、世界のどこ(どの空港周辺)に誰がいるかを、SVGを用いて下図のように示してくれます。
位置データと精細度
Sometimes the precision of the lat/long matters. A hint is: 0.01 degree of latitude is about 1.11 kilometers, while 0.01 deg. of long. is about 0.91 km.
緯度・経度データの小数点以下を何桁示しておくのがよいかは、データをどんなスケールで利用するかによって違ってきます。特定の場所にカーナビなどを使ってたどり着くためにはかなりの精細度が必要である一方、世界地図の中でおよその位置をプロットするのであれば、低精細度の値で十分です。また対象となるデータによっては、プライバシーとの兼ね合いも精細度に関係するでしょう。
大まかに言って、緯度の0.01度は約1.11km、経度の0.01度は約0.91kmの距離に相当します。従って、10m単位の精細度が必要な場合は小数点以下4桁、10km単位でもよければ小数点以下1桁といった形でデータを提供すればよいわけです。
カレンダーと位置情報
iCalendar format defines GEO property. Although it is not yet determined how to encode it in RDFical, it will be a good place to use geo: vocab.
iClarendarにはGEOというプロパティがあり、ここに緯度・経度をセミコロンで区切って記述することになっています。iClarendarのRDF版、RDFicalでこの値をどう扱うかについては、まだ確定していませんが、geo:語彙を持いて構造化した記述が有力候補になっています(次の例では、RDFicalの名前空間をデフォルトとしてVevent要素のみを記述します)。
(例)
<Vevent> <dtstart rdf:parseType="Resource"> <dateTime>2004-02-11T18:15:00</dateTime> <tzid>Asia/Tokyo</tzid> </dtstart> <dtend rdf:parseType="Resource"> <dateTime>2004-02-11T21:00:00</dateTime> <tzid>Asia/Tokyo</tzid> </dtend> <summary>オーケストラ・ダスビダーニャ第11回演奏会</summary> <location>東京芸術劇場</location> <geo
rdf:parseType="Resource"> <geo:lat
>35.7297</geo:lat
> <geo:long
>139.7080</geo:long
> </geo
> </Vevent>
(場所の名前を示すlocationプロパティと緯度・経度のgeoプロパティが別々になっているのがイマイチなので、この辺りの構文は変更されるかも知れません)
Followings are the examples to use geo: vocab in RDFical, and their representations with RDFmapper. Note RDFmapper requires Flash6.
イベント情報に緯度・経度を結びつければ、カレンダーをクリックするとその場所の地図が表示されるといった応用が簡単に実現します。例:
- シュトゥットガルト放送響2004来日公演カレンダー、およびRDFMapperによる地図生成のテスト(ブラウザによっては文字化けの可能性あり)
- ニューヨーク2003年5月コメディカレンダーのサンプル、および同じくRDFMapperによる地図生成のテスト
※[RDFMapper]での地図生成にはFlash6が必要です。これについては別途解説の予定…
GeoURL
GeoURL is an interesting database of web sites based on their locations, though it does not take RDF format yet.
今のところRDFベースではありませんが、緯度・経度情報に基づいて世界のホームページを収集しているデータベースが[GeoURL]です。自分のサイトをGeoURLに登録するには、まず次のようなmetaタグをホームページのhead要素内に記述します。
(例)
<meta name="ICBM" content="35.678, 139.770" /> <meta name="DC.title" content="The Web KANZAKI" /> <link rel="schema.DC" href="http://purl.org/dc/elements/1.1/" />
name属性値がICBMとなっているのは、インターネット以前のUsenet時代のプロジェクトの呼び名にちなんでいるそうです。content属性には、百分率の緯度・経度をカンマで区切って記述します。サイトの名前は、なぜかHTMLのtitle要素から取得されず、改めてもうひとつのmetaタグを用意してDC.titleとして記述することになっています。最後のlink要素は、GeoURL用ではありませんが、Dublin Coreの語彙をHTMLに記述するための約束です。
これらのタグを記述してアップロードした上で、GeoURLのページからリクエストPINGを送ると、指定URLのタグをチェックしてデータベースに加えてくれます。
データベースからは、地図をクリックしたり、北緯35.678度・東経139.770度から半径100マイルにあるホームページ、あるいは自分のURLの近所にあるサイトといった具合に指定して、「ご近所さん」を見つけることができるようになっています。
GeoURL, on the other hand, supports RDF as an output. RFDmapper can draw a map based on its output.
GeoURLは、出力データとしてはRDFをサポートしています。これを使うと、RDFMapperでご近所さん地図を描くなど、面白い試みが可能になります。
〔補足〕
2004年の夏頃からGeoURLのサービスは停止していますが、2004年末から、別のドメインhttp://geourl.info
で類似のサービスが始まっています。ただしこちらの機能は限定的で、今のところRDFの出力もない模様。当サイトのメモ「GeoURLふたたび?」を参照してください。
2005年2月にはGeoURL 2.0として元祖も復活しました。当サイトのメモ「GeoURLふたたび?」を参照してください。
〔以上補足〕
GPSとデジタル写真
Digital photo and GPS is a good combination. Exif format has directory and tags for GPS data.
デジタル写真の撮影データなどを記録するExifフォーマットには、GPSの緯度経度情報などのためのディレクトリ・タグも定義されています。GPS付きの携帯電話カメラも登場しており、写真に位置情報を追加するのはずいぶん身近になってきました。これを利用すると、地図と写真を組み合わせたサービスなどが簡単に提供できます。
Exifでは、緯度・経度情報を(1)北緯/南緯を示すGPSLatitudeRef、(2)緯度の数値を示すGPSLatitude、(3)東経/西経を示すGPSLongitudeRef、(4)緯度の数値を示すGPSLongitudeの4つのタグを使って表します(GPSデータとしては、高度、衛星のIDや位置、測地系なども記録できます)。緯度・経度の数値は度分秒形式で、Exif特有の表記法を用います。例えば、北緯35度41分7.74秒、東経139度48分7.74秒というGPSの緯度経度は、Exifでは次のような具合です(実際はバイナリ形式ですが、仕様書の説明形態に合わせて示します)。
(例)
GPSLatitudeRef : N GPSLatitude : 35/1,41/1,774/100 GPSLongitudeRef: E GPSLongitude : 139/1,48/1,774/100
With Exif data description vocabulary in this site, Exif GPS data can be encoded as an RDF...
当サイトの定義しているExif data description vocabularyでは、今のところこのデータをRDFとして次のように表しています。
(例)
<IFD rdf:ID="Primary_Image"> ... <gpsInfo_IFD_Pointer> <IFD> <gpsLatitudeRef>N</gpsLatitudeRef> <gpsLatitude>35/41/7.74</gpsLatitude> <gpsLongitudeRef>E</gpsLongitudeRef> <gpsLongitude>139/48/7.74</gpsLongitude> </IFD> </gpsInfo_IFD_Pointer> </IFD>
... but the native Exif format is not compatible with geo: vocab, my Exif2rdf also generates geo: properties.
元のExifデータの形をあるていど尊重しているわけですが、汎用性に劣るので、当サイトのツールExif2rdfは、合わせてこのデータをGeo vocabularyのプロパティに変換して出力します。
(例)
<foaf:Image> ... <foaf:topic rdf:parseType="Resource"> <geo:lat>35.685483333333</geo:lat> <geo:long>139.80215</geo:long> </foaf:topic> </foaf:Image>
デジタル写真からExifデータをRDFとして抽出すれば、例えばXSLTを使って簡単に地図サービスへのリンクなどを加えることができます。
携帯電話デジカメ/メールによるウェブログ(moblog)のサービスにはGPSデータを扱う機能を備えたものがあるようですし、これらを地図上に表示したりする試みもいくつか登場しています。これらの多くはRSSを提供しているので、緯度・経度情報をgeo:で表現してここに含めてくれると(例えば次のように)面白いのですが。
(例)
<item rdf:about="http://www.kanzaki.com/works/2003/imagedesc/0817.jpg"> <title>Summer Fest</title> <description>江東区森下のお祭り。御輿の行列が練習会場の前で…</description> ... <foaf:topic rdf:parseType="Resource"> <geo:lat>35.685483333333</geo:lat> <geo:long>139.80215</geo:long> </foaf:topic> </item>
位置データとデジタル画像とRSSを組み合わせて地図連動型アルバムをつくる実験を行っています(ここでは[Blogmapper]も利用しています)。また、画像のメタデータ表現については、以下のページも参照してください。
GPSのトラック・ログ
The GPStrack by Matt Biddulph is another example to utilize GPS data as RDF.
ハンディGPSを使って移動ポイントを記録しているアウトドア派なら、Matt Biddulphの[GPSTRACK]も面白いかも知れません。xmlns:gps="http://hackdiary.com/ns/gps#"
と名前空間URIを宣言した上で、gps:Tracklog
クラスとgps:trackpoint
プロパティを使ってGPSが記録した日時と緯度経度を記述していきます。
(例)
<gps:Tracklog
> <gps:trackpoint
dc:date='2003-08-08T06:58:47Z' rdf:type='http://www.w3.org/2003/01/geo/wgs84_pos#Point'geo:lat
='52.5816178322'geo:long
='13.6952733994'/> <gps:trackpoint
> <geo:Point
> <dc:date>2003-08-08T06:59:15Z</dc:date> <geo:lat
>52.5815534592</geo:lat> <geo:long
>13.6953377724</geo:long> </geo:Point> </gps:trackpoint> ... </gps:Tracklog>
この例では2通りのgps:trackpoint
の記述方法を挙げていますが、どちらもRDFとしては同じモデルです。1番目の、すべてをgps:trackpoint
要素の属性にするのが、MattによるPythonプログラムgarmin2rdf.pyの出力です。
位置情報と距離
With lat/long data of two points, the distance between those points can be calculated.
2つの地点の緯度と経度が分かれば、2点間の直線距離を算出することができます。GeoURLの「ご近所さん」は、緯度・経度情報をもつメタデータを集積し、「近くにあるリソース」を見つける好例です。イベントカレンダーで好みの演奏会を探し、そこから近隣のレストラン情報をリストアップするといった応用が考えられます。
距離の計算
「半径何m以内にあるレストラン」という形ではなく、「東西、南北それぞれ○kmの升目に含まれるもの」といった方法でよければ、より単純な緯度経度データの比較だけでリソースを検索することができます。緯度の0.01度(36秒)はおよそ1.11km、経度の0.01度(36秒)はおよそ0.91kmに相当することを利用して、必要な範囲の緯度・経度の最小・最大値を計算し、その範囲に収まるものをピックアップすればよいわけです。
実際には、近くのレストランに行くのに直線コースをたどれる訳ではないうえ、交通手段の有無にも左右されるので、緯度・経度だけによる「近くのレストラン」というのは単純に過ぎるかも知れません。それでも、候補を絞り込む手段としては十分役に立つでしょう。
GeoOnion:距離感覚の語彙
Straight distance might not be appropriate information in some cases (traffic etc. matters more). In order to express the levels of 'near' or 'far', RDF-IG members made a unique vocab called GeoOnion, with powers of three meters as its scale.
アプリケーションがメタデータから距離を計算するだけでなく、距離そのものをプロパティとして直接リソースどうしを関連づけることも可能です。foaf:based_nearなどはまさに「近い」という関係を示すわけですが、どの程度近い(遠い)かを何段階かの遠近レベルで表現できると便利かも知れません。
一般にこの「近い、遠い」といった尺度は、線形的な比例関係よりも、指数的に表現する方がより感覚に合う実用的なものとなります。10km,20km,30kmという刻みよりも、1km,10km,100kmという段階の方が、「遠近レベル」を示すには使いやすいのです。
RDF Interest Groupのメンバーたちは、これを表現する方法についてディスカッションした結果、3mのN乗というステップがちょうど良さそうだという結論に至り、ユニークな語彙[GeoOnion]をつくりあげました。
- 名前空間URI
http://www.w3.org/2003/01/geo/go#
- よく使われる接頭辞
go:
乗数 | プロパティ | Metres | Kilometres | 渋谷から |
---|---|---|---|---|
0 | go:within_3_power_0_metres | 1 | 0.001 | 〔密接/個体距離〕 |
1 | go:within_3_power_1_metres | 3 | 0.003 | 〔社会距離〕 |
2 | go:within_3_power_2_metres | 9 | 0.009 | 〔公衆距離〕 |
3 | go:within_3_power_3_metres | 27 | 0.027 | (野球の塁間) |
4 | go:within_3_power_4_metres | 81 | 0.081 | (狭い球場の両翼) |
5 | go:within_3_power_5_metres | 243 | 0.243 | JR駅から109 |
6 | go:within_3_power_6_metres | 729 | 0.729 | 〜青山学院前 |
7 | go:within_3_power_7_metres | 2187 | 2.187 | 〜外苑前 |
8 | go:within_3_power_8_metres | 6561 | 6.561 | 〜東京駅 |
9 | go:within_3_power_9_metres | 19683 | 19.683 | 〜市が尾(横浜市) |
10 | go:within_3_power_10_metres | 59049 | 59.049 | 〜国府津 |
11 | go:within_3_power_11_metres | 177147 | 177.147 | 〜掛川 |
12 | go:within_3_power_12_metres | 531441 | 531.441 | 〜岡山 |
13 | go:within_3_power_13_metres | 1594323 | 1594.323 | 〜大連 |
14 | go:within_3_power_14_metres | 4782969 | 4782.969 | 〜バンコク |
15 | go:within_3_power_15_metres | 14348907 | 14348.907 | 〜ケープタウン |
16 | go:within_3_power_16_metres | 43046721 | 43046.721 | 地球一周 |
17 | go:within_3_power_17_metres | 129140163 | 129140.163 | ? |
18 | go:within_3_power_18_metres | 387420489 | 387420.489 | 月 |
最初の3レベルは、地理的というよりもエドワード・ホールのプロクセミックスに一致する感じで、興味深いです[HALL]。この尺度がどのていど感覚にマッチするか、いろいろ捉え方はあると思いますが、距離を数値化するだけでなく、こうした「レベル」として見るというのはなかなか面白い考え方だと思います。
※RDF-IGはイギリス系のメンバーが中心になっているので、プロパティの綴りがmetersではなくmetresとなっています。ご注意を。
GeoOnion語彙を使ってみる
ある地点までの行き易さは、直線距離よりも交通手段などによって左右されるので、厳密な距離よりもこうしたおおまかなレベルの方がかえって適切かも知れません。例えば、あるホテルの近くにあるレストランをリストアップする際、歩いていけるA店(3^6=約700m圏内)、地下鉄で一駅程度のB店(3^7=約2.2km圏内)、などといった形で示すことができます(wn:はRDF版WordNetの名前空間とします)。
(例)
<wn:Hotel rdf:about="http://example.org/hotels/niceHotel"> <go:within_3_power_6_metres
> <wn:Restaurant rdf:about="http://example.org/restaurants/A"/> </go:within_3_power_6_metres
> <go:within_3_power_7_metres
> <wn:Restaurant rdf:about="http://example.org/restaurants/B"/> </go:within_3_power_7_metres
> </wn:Hotel>
GeoOnionのプロパティは、2点のうちいずれかの緯度・経度があまりはっきりしない(させる必要がない)時などにも使えます。foaf:based_nearで自宅の緯度・経度をピンポイントで示したくはないでしょうから、近くのランドマークの緯度・経度を使い、そこが自宅からどの程度の範囲にあるかを表しておくという方法です。自宅から6.5km程度以内の地点を使ってbased_nearを表現するなら、次のような具合になります。
(例)
<foaf:based_near rdf:parseType="Resource"> <go:within_3_power_8_metres
> <geo:Point> <geo:lat>35.678</geo:lat> <geo:long>139.770</geo:long> </geo:Point> </go:within_3_power_8_metres
> </foaf:based_near>
現時点での実用性のほどはともかく、感覚的な尺度に近いものをメータデータ記述の語彙に取り込むという考え方は、いろいろ可能性がありそうです。
世界測地系と日本測地系
This section explains the two datum systems in Japan, and discusses how to transform geo data between two datum.
ある地点の緯度・経度値は本来唯一に定まるはずですが、実は基準の取り方によって異なる値が併存するというややこしい事態になっています。日本では、従来は明治以来の測量基準によって緯度・経度を求めてきましたが、2002年4月1日に新しい測量法が施行され、人工衛星や電波望遠鏡に基づく世界基準に移行しました[G2000]。一般に前者を日本測地系(Tokyo Datum)、後者を世界測地系(WGS84)と呼んでいます(※注)。
GPSやGISの利用が進む中、グローバルに同じ尺度を用いる世界測地系への移行は必然的ですが、2003年末現在ではまだ日本測地系に基づく地図もまだたくさん使われており、2つの測地系が混在している状況です(オンライン地図サービスの多くは日本測地系です)。両者の座標は、東京付近で約450mずれていて、具体的な場所を記述するためには、ちょっと大きすぎる誤差となっています。
緯度・経度情報を取得する際は、その測地系も合わせて確認しておくことが重要です。また、メタデータを記述する場合は、(もしデータが日本測地系なら)世界測地系に変換すること、メタデータを利用してオンライン地図サービスなどと連動させる場合は、地図の測地系をチェックすることも忘れないでください。
※厳密には、新しい日本の測地基準点である測地成果2000は、GPSの基準である世界測地系(WGS84)ではなく、1994年の国際地球基準座標系(ITRF94)および測地基準系1980(GRS80)に基づいていますが、実質的には同じと考えて差し支えありません[GEOTERMS]。
測地系の変換
日本測地系と世界測地系の座標は、幾何学的な計算で相互に変換が可能です。以下のフォームでは、Javascriptによる変換を試してみることができます(厳密には、基準点のひずみの補正が必要です。より精度の高い変換のためには、国土地理院から提供されているツール[TKY2JGD]などを利用してください)。
参照文献
And, references.
- [GEOVOCAB]
- RDFIG Geo vocab workspace ,
- <http://www.w3.org/2003/01/geo/>
- [GeoInfo]
- GeoInfo ESW Wiki, ESW Wiki ,
- <http://esw.w3.org/topic/GeoInfo>
- [AIRPORTLOC]
- Airport Locator, Air Routing International
- <http://www.ar-group.com/icaoiata.htm>
- [GeoURL]
- GeoURL ICBM Address Server ,
- <http://geourl.org/>
- [MILLER]
- Semantic Web Developer Map: representing locations of people, research groups and projects, ,
- <http://www.w3.org/2001/sw/Europe/200303/geo/intro.html>
- [RDFMapper]
- RDFMapper: an RDF-Based Web Mapping Service, Map Bureau
- <http://www.mapbureau.com/rdfmapper/>
- [Blogmapper]
- Blogmapper- map your blog and blog your map, Map Bureau
- <http://www.blogmapper.com/>
- [GPSTRACK]
- Dumping Geo RDF from Garmin GPS units, ,
- <http://www.hackdiary.com/archives/000040.html>
- [GeoOnion]
- GeoOnion ESW Wiki, ESW Wiki ,
- <http://esw.w3.org/topic/GeoOnion>
- [HALL]
- , The Hidden Dimension,
- <ISBN:0385084765>
- 邦訳『かくれた次元』1980,みすず書房,ISBN:4-6228-00463-1
- [G2000]
- 世界測地系移行の概要, , 国土地理院, Ver 1.0
- <http://www.gsi.go.jp/LAW/G2000/g2000.htm>
- [GEOTERMS]
- 世界測地系用語集, 国土地理院
- <http://www.gsi.go.jp/LAW/G2000/g2yogo.htm>
- [TKY2JGD]
- Web版TKY2JGD, 国土地理院
- <http://vldb.gsi.go.jp/sokuchi/tky2jgd/>