道端で事故や病人を発見した時、その場所の住所や近くのAEDを探せます。 道端で事故や病人を発見した時、110番や119番へ通報したけど、住所がわからないってことありますよね。 そんな時、このアプリを立ち上げてもらうと、住所を知ることができます。 また、一番近くのAEDまでの道のりも表示することができるので、一刻も早くAEDが必要な場面でも役立ちます。 AEDが遠くにある時も安心、ヘルプの要請ボタンでお助けチーム（有志・ボランティア）に連絡する機能もあります！ 今後の課題としては、要請を受けて駆け付ける前に「駆け付けます」という登録を行い、ヘルプが被らないようにしたいと思います。 アプリは「Monaca」で開発を行いました。 住所は現在の位置情報から「HeartRails Geo API」より取得します。 AEDの一覧は「AEDオープンデータAPI」より取得を行い。 道案内は「Google Maps API」を利用し、AEDの場所までナビゲートします。 ヘルプの要請ボタンを押すと、予め「kintone」に登録しておいた有志やボランティアの方へ「SendGrid」を使い、メールでお知らせします。

職場から炊飯器を操作して、帰宅時に炊きたてのご飯が食べられるようにするアイディアです。 チーム名：たきたてゴハン

・つっぱり棒にボタンをつけて、あごで押すとブラウザ上でカウントが取れるようにします！これで割れた腹筋を手に入れます！

海の景色をガイドするアプリ。夜景の光や旗の色を解説したり、ARでガイドする。

「自分をもっと知りたい」 普段の作業を効率良くこなすためには自分を知ることが大切です。 このシステムは自分がどんな時にどのように集中していくのかを可視化します。 集中力の変化を見ることで、これまで気づかなかった集中するまでのパターンを知ることができます。

OpenWorks（オープンワークス）は、街中で発見した問題の共有・様々な要望をお聞きし、解決を図る仕組みです。

もっとおしゃれに！ 羽根なし扇風機のように！ さらにセンサーやカメラもつける。 自分で動いて効率アップ エクステリアに。 気象データなどビッグデータに使って ゲリラ豪雨から逃げる。

要介護者の「自分でできることを自分でやりたい！」をサポートするアイディアやデータを集めます。

多忙な営業マンの訪問効率を上げるための渋滞情報をベースとした訪問ルート編成アプリです。

ヨコハマ大好きな横浜市職員有志勉強会「よこはまYYラボ」のメンバーがおススメするスポット一覧です。 超ポピュラーな場所から「え、こんなところあるの？」まで色々取り揃えております！ ※注：横浜市役所の公式ではありません。

サービスというものは無形で属人的な部分があります。そにてそのサービス内容であるContentには提供する側と受け手側の価値観の違い、情報の非対称性の問題があります。今回それを限りなく見える化し、幅広く一般のサービスデザインのイノベーションを促進するデザインフレームワークを提供するものです。これにより今後のオープン化された情報がＬＯＤという情報の共有基盤上にデータとＡＩアプリケーションとのメタ・メタレベルでの融合を図ることができます。つまり意志や意図、意味による文脈的結合です。 詳細な内容はリンクＵＲＬの関連ページをご参照ください。具体的には、その観光スポットを紹介するムービーや概要を示すものをContentとして定義し、それに地理情報や観光サービス情報やWikiなどの情報＝metaContentとし、その情報リソースのＵＲＬなどをメタデータとします。 ここで、更に加えるに上述の旅行者の行為を促す動的な意味‐意図情報をメタメタデータと定義し付加します。これは観光関連での事例ですが、データセットをこのような基本構造をもたせることで、サービスやコンテンツ設計のイノベーションを興すことができます。サービス提供側と受け手の価値観を見えるかしマッチングさせ個別対応をコストアップなしに実現すること、関連するデータがＬＯＤのようなオープンな気情報基盤で実現することが本アイデア提案の狙いです。 イノベーションのもう一つの側面は、コンテンツ作りの生産性を著しく向上、個別対応を行うときに、その変更や再編集をできる限り自動化することです。本アイデア提案に使用されているＭＭオーサリングツールはノンプログラミングでメタデータを生成します。今回そのメタデータにさらなるメタメタデータなるものを付加し、データ自身に動的な意味合いを与えることができます。 今後のサービス設計やコンテンツ設計にはＡＩの導入がどんどん行われてきますが、今回のようなデータ、メタデータ、メタメタデータ構造（スキーマ）を標準化しＬＯＤに登録公開することで、データに関する意味や意図に基づいたデザインを行う基本的なフレームワークを提供します。今回の対象素材はマレーシア　クアランプールですが、ＬＯＤチャレンジ2014でデータセット部門で提案した「神奈川名所31」に関しても同様の作業を進めていきます。既に提案応募時点でcept,Contextメタ情報を書き込む入れ物を用意してあります。 更新: 2017年1月15日 説明追加情報 http://idea.linkdata.org/idea/idea1s2190i

開港5都市まちづくり景観会議に加盟する港まちデータです。

現在日本には国公立、私立全てを併せて780校ほどの大学があるが、そこでの教育内容に関しては、シラバスという形式で、その科目の詳細が公開されている。しかし各大学で公開レベルやフォーマット、スキーマなどが統一されておらず、学外からそれらを閲覧することするら困難である。本プロジェクトでは、大学のシラバスをオープン化し、大学教育を俯瞰することを目指す。

・皆の町の「地理空間情報」は、皆で育む。 ・OpenStreetMapを始めとする地理空間情報 　は、オープンデータ活用の根幹であり、 　その充実はアプリの飛躍的な活用を促すが、 　充実度合は地域間で異なるのが実情である。 ・小学校３，４年生の社会科学習では、自分達の 　学校周辺の地理を調査する取り組みがある。 ・これをきっかけに、地理空間情報として活用 　できるまでの整形過程を小～中・高校、さらに 　専門学校と、情報化教育の一環として 　襷を渡し、自ら育む取り組みとして提言する。

カレーうどんはおいしい。 ネット検索してもなかなか食べられるお店が見つかりにくいですが、 和食屋さん、うどん屋さん、蕎麦屋さんでもカレーうどんは食べられますよね。 カレーうどんが食べられるお店と、そのお値段など。

縦方向に自由度をもたらすつっぱり棒を活かし、観葉植物を様々な高さにおけるようにする。かつ、必要に応じて水やりをしてくれる。

　近年、高校授業における課題研究が多くの学校で行われるようになり、教育的な点からも重要視されています。実際に、課題研究の授業は、僕達の通う横浜サイエンスフロンティア高校でも取り組まれており、力を入れている事例の一つです。朝日新聞により主催される高校生科学技術チャレンジや、毎日新聞の日本学生科学賞など、全国的な規模の高校生研究の大会も行われており、高校生研究は年々広がりをみせその質が高まっているといえます。 　僕たちは、１２月１９日に「JSTリンクト・データを使い倒そう」に参加し、J-GLOBAL knowledgeにSPARQLを使って触れました。そこから、実際に課題研究に取り組んだ人間として、その経験をもとに、日本全国の後輩たちの研究を手助け出来るようなアプリケーションを作ることが出来るのではないかと考え、本アイディアを提案します。

B2Cサービスである「旅ぷら」に掲載している全国27都道府県の公式観光スポットコンテンツを活用し、ホテル、旅館、民宿等宿泊施設がおもてなしサービスを容易に提供できるB2B2Cサービス「旅コン」（旅のコンシェルジュサービス）を準備中です。サービス開発に興味を持って頂ける方、販路開拓にご協力頂ける方、オープンデータ化に向けた取り組みにご協力頂ける方を集っております。

【利用しているオープンデータ】 なし 【利用しているパートナーリソース】 linkdata(linkdata.org） 【エントリー作品の詳細説明】 鳥がもともと好きなので、たまに鳥カフェに行きます。 鳥カフェをまとめたものがないので、困っていました。 そこで、鳥カフェのデータをつくろうと考えました。

近所の人が作った料理を500円で購入できるCtoCのサービスのアイディアです。

熊谷市内の雪くま（熊谷しか味わえないかき氷）販売店27店舗が登録されてます。 右下のKMLの部分をクリックするとダウンロードできます。

1.概要 従来のLODを物理世界とつなげるプラットフォーム「サイバー・フィジカルLOD:CPLOD」を提案します。CPLODは、LODにつぎの機能を加えたものです。 ・物理世界との双方向接続 ・リアルタイム性 ・秘密の制御 これらの機能によってLODを身の回りのあらゆる情報処理へ適用できるようにし、クラウド、モバイル、IoTをオープンな仕様で連携させ、少子高齢化、地球環境の変化などの課題にITを活用できるようにします。 2.セールスポイント：ITデバイスの総連携によりITの可能性を使い切る 現在のITデバイス（クラウド、モバイル、IoTなど）は、十分な発展をとげ、様々な問題を解決するツールとなる可能性を秘めています。たとえば、個人の身の回りのデバイスを連携させれば、社会や家族の負担を少なくしながら高齢者を見守り、介助するようなシステムを作れるでしょう。 あるいは、市町村、都道府県、国といった様々なレベルでリアルタイムに地域の状況のセンシングを行って情報を共有できるシステムや、全住民が参加するコラボレーションツールのようなシステムを作ることができるでしょう。縮小していく経済に対応しながら、資源やエネルギーを効率化し、拡大する失業、高齢化、少子化などの対策をとるツールとするといったことが可能となるはずです。 しかし、現在このようなシステムはまだありません。その原因は、任意のデバイスや人を連携させることができないという、分断化にあると考えます。ITの分断化には３種のタイプがあります。 (1)APIやプロトコルなどの、規格の乱立による分断 企業やグループによる囲い込みや、異なる目的のプロトコルの存在によって、ユーザが自分の使いたいデバイスを自由に連携させることができません。特定メーカーのデバイスとそのメーカーの認証を受けたデバイスを連携させてスマートハウスを実現するといった試みは存在します。しかし、あらゆるメーカーのあらゆるデバイスを連携させることはできません。 (2)規格の不在 IT化を推進するメーカーやユーザがいない分野や、異なる分野をつなぐ用途には、IT化のための規格を作る動きがありません。たとえば高齢者の生活を支えるために、介護サービス産業・行政・ボランティア・ご近所・出入り業者などの、地域社会の様々なステークホルダが現場で連携するようなITシステムを作ろうとしたとき、様々なシステムを連携させるための規格を作るのは誰でしょうか。本来は現場でシステムを作る人たちが規格を作ることができれば理想的です。しかし、規格を作るというスキルは現状では期待できません。 (3)世代交代（陳腐化）への対応 APIやプロトコルは新しい技術が生まれるたびに更新され、その周期は人の一生や人の世代交代といった時間軸に比べれば著しく短いものです。黎明期をとっくに過ぎたITですが、まだ数十年以上にわたる連続運用には耐えられません。過去と未来の連携を可能とする必要があります。 たとえば、つぎのようなユースケースを実現可能としなければなりません。 ・10年後のシステムに対して、家屋の10年点検時に確認すべき項目を指示する。 ・築20年のスマートハウスシステムに、新しいデバイスを接続する。 ・30年後のシステムが現在のセンシングデータを参照する。 そこで私たちは、LODのアーキテクチャを使って、この分断化の問題を解決し、あらゆるITデバイスを連携させることと、この目的のために、LODに不足している機能を追加することを提案します。 3.提案者 先端IT活用推進コンソーシアム（AITC） ビジネスAR研究部会（http://aitc.jp/wg/ar/） 連絡先：リーダー　大林勇人、サブリーダー　中川雅三、吉田光輝 4.実装方法 4.1.物理世界との双方向接続 CPLODでは、デバイス上のサービスをRDFデータにマッピングし、RDFデータを書いたり読んだりすることでサービスを利用できるようにします。 メモリマップドI/Oの考え方を、RDFデータに適用するというアイデアです。 ・サービスのユーザがサービスへのリクエストをあらわすデータをRDFストアへ書き込むと、サービスの提供者はそれを読み出して実行する。 ・サービスの提供者がサービスの結果をRDFストアへ書き込むと、サービスのユーザがそれを読み出して利用する。 単純な例を示します。 ・指定した場所の照明をオン・オフする 照明のユーザは、つぎのような形で居間の照明を"ON"とするリクエストをRDFストアに書き込みます。 DELETE{ ?sw :制御要求 ?current . } INSERT{ ?sw :制御要求 "ON" . } WHERE { ?sw :所在 :居間 . ?sw :種別 :照明スイッチ . OPTIONAL { ?sw :制御要求 ?current . } } 照明制御を提供するサービスは、制御要求データを監視し、値が変化したときに、その値を照明スイッチへ反映します。 ・指定した場所の温度を取得する。 温度計のユーザは、つぎのような形で温度データを取得します。 SELECT{ ?temp } WHERE { ?sensor :所在 :居間 . ?sensor :種別 :温度計 . ?sensor :測定値 ?temp . } 温度計のデータを提供するサービスは、温度データを取得するたびにRDFへ値を書き込みます。 語彙とデータ構造を定義してゆくことで、もっと複雑なサービスのインタフェースもRDFデータとして定義することもできます。たとえば、つぎのようなリクエストをSPARQLで表現できるだろうと考えています。 ・Aさんが歩いている付近の街灯を点灯する。 ・河川が氾濫の警戒水位に近づいている地域の低地にある家に住んでいる住人全員へ、警戒を促すメールを送信する。 4.2.APIにLODを使うメリット LODによってつぎのようなメリットが得られ、先に述べた3つの分断化をすべて解決することができます。 (1)プロトコル、データ構造、メタデータの記述方法を統一できる。 プロトコルはHTTP、語彙はRDFで統一できます。 メタデータを記述するオントロジーを定義することで、データ構造や機能の意味も機械可読な形で記述可能です。このことにより、つぎの利点が生まれます。 1)LODへアクセスするライブラリを用意するだけで、任意のOS、任意のプログラミング言語からAPIを利用することができる。 既存のAPIの多くは、特定のOSや特定の言語にしか対応していません。 2)世界中のすべての情報やサービスを扱える。 IRIを使って独自の語彙を作り、オントロジーを定義することで、あらゆる用途に応用できます。 既存のAPIについて、LOD へマッピングする語彙をそれぞれが衝突しないように定義することができます。 3)異なる用途のために作られたAPI群を同時に利用することができる。 既存のAPIはOSや言語に依存するため、異なるOSや言語で実装されたAPIを同時に使うことができません。 　　 (2)現場からのボトムアップによる規格化が可能である。 これまでの規格は、少数の企業やグループが時間をかけて作るトップダウンな方式で作成されてきました。 このような作り方では、実社会の多様な活動分野それぞれに対応したり、必要なときに迅速に対応できるような規格化は不可能です。実際の問題解決を行う現場の人々が試行錯誤しながらAPIを作り、様々な提案から有力なものが進化していって「規格」となるという、ボトムアップな規格化（デファクトスタンダード）が現実的な手段となるはずです。 LODでは名前空間を厳格に区別し、語彙を厳密に定義できます。現場の人々は、LODでAPIを設計することで、規格の記述が完了します。LODを使うことによって、多様な規格の乱立という初期状態を整然と実現し、それらを統合したり、変換したりしていくつかの規格に収束させることができるようになります。 (3)IRIで名前空間を分けることができるため、世代によって変遷するAPIを共存させることができます。 機械可読なメタデータにより、異なるAPIや、異なる世代のAPIの間の自動変換技術を開発することもできるようになります。LODは十分に抽象化され、厳密に定義されているため、数十年後でも現在定義したデータを容易に扱うことができるはずです。 4.3.LODに欠けている機能の追加 これまでに述べたことを現在のLODで実現するには、つぎの課題があります。 (1)リアルタイム性 論理的には、上記の方法だけで、既存のRDFストアとSPARQLを使って任意のAPIを実現することができます。しかし、SPARQLクエリの処理オーバヘッドが大きく、システム負荷を抑えながら、リクエストへの応答性能を確保することが困難です。例えば、先述の「居間の照明制御」の例では、照明を制御するデバイスは、自分宛の制御要求が書き込まれるまで、SPARQLクエリを繰り返し実行しつづけなければなりません。 多数のデバイスをRDFストアに接続したとき、膨大な量のSPARQLクエリが繰り返し実行されることになり、大きな負荷が生じ、応答性能も低下することになります。 (2)アクセス権限の制御 LODでは、すべてのデータを公開します。しかしすべてを公開する前提では、あらゆるサービスをLOD化することはできません。プライバシー情報へのアクセスや、セキュリティ確保が必要なサービス利用では、個別のデータやサービスを、相手によって公開したり非公開としたりする制御をできるようにする必要があります。 CPLODでは、上記の課題をLODにふさわしい形でRDFストア機能を拡張します。 (1)WebSocketによる、RDFデータ変化の通知 RDFストアにWebSocketインタフェースを設けます。 ・読み出しインタフェース：指定したRDFデータ項目の変化を通知する。 ・書き込みインタフェース：指定したRDFデータの書き換えを通知する。 サービス提供デバイスは、WebSocketによってRDFストアへ接続し、リクエストの監視と、提供データの更新を行うことで、リアルタイム性を確保します (2)アクセス権限を制御するメタデータ設計及びSPARQLの改造 すべてのRDFストア内データについて、個別にアクセス権限を設定する語彙を定義し、その語彙にしたがってアクセス許可を制御する機能をSPARQLクエリエンジンに実装します。 具体的にはRDFデータにアクセス権限を示すデータを付加してアクセス制御します。アクセス権限を示すデータ自身もRDFで記述します。 ・クラスのプロパティに権限を設定 ・インスタンスのプロパティに権限を設定 ・IRIにアクセス権限を設定 といった記述方法を定めています。 アクセス権限はつぎの3レベルです。 ・レベル1:外部へ公開可 ・レベル2:推論に利用可だが、外部への公開不可 ・レベル3:推論に利用不可かつ、外部へも公開不可 5.進捗状況及び今後の予定 開発シナリオとして、2段階を予定しています。 (1)概念を実証するために、モックアップを作成する。 モックアップでは、既存のRDFストアをそのまま使い、RDFストアへのラッパーとしてCPLODの機能拡張を実装します。ラッパーによる実装はつぎの欠点がありますが、実装が比較的単純で、動作を短期間に評価できるメリットがあります。 ・最高のパフォーマンスを得られない：ラッパーが外部からのSPARQLリクエストを解釈し、既存のRDFストアへのSPARQLリクエストを自動生成します。SPARQLの解釈や生成のオーバヘッドが発生します。 ・完全なアクセス権限制御をできない：プロパティパスなどのRDFストア内部で多重のリンクをたどる処理が実行されるとき、途中のリンクに対する権限チェックを実装することができません。 (2)本格的な実装を行う。 SPARQLクエリの処理エンジンを、CPLOD仕様へ改造します。 現在は(1)のモックアップが、一部の動作を開始したところです。 詳細は以下の「6.現時点のモックアップ「空間OS」」に記します。

・IT進展の課題も踏まえた活動開始すべく、以下を含めた提案を行いたい 　　　→学校教育でのオープンデータ生成「襷」リレー 　　　→職場OB（高齢者）による支援・コンシェルジュ ・IoT/IcTの進展著しく、大いなる期待有。 　少し前の「夢」が一躍現実的なものに！ 　　（シンギュラリティが近い：IoTデバイス暴発） 　　（「みちびき」で精度UP：GPS誤差数m→数cmへ） ・一方で、超高齢化社会によるデジタルデバイド/IT弱者拡大を懸念 ・「夢」を描き続ける一方、核となるオープンデータ充実が急務 ・その時「人も主役！」

和歌山県橋本市版5374.jpです。

玄関にて出勤前に髪型服装チェックをする際に後ろも写してくれる姿見機能付きつっぱり棒

Don’t guess when choosing an LED batten. Start with the space you’re lighting — is it a long corridor, a damp basement, a warehouse bay or a stairwell? Once you know that, the rest falls into place: size, lumen output, beam spread, mounting style and the right sensors or emergency backup. Why “LED batten” matters for performance and cost An LED batten is a slim linear fixture designed for efficient, even lighting. Compared to ad-hoc tube retrofits, a purpose-designed LED batten reduces glare, simplifies wiring and lasts longer — which matters when you’re planning maintenance cycles and total cost of ownership. Key factors to consider when choosing a LED batten Application & environment (where the LED batten will live) Match the batten to the environment first. For wet or dusty areas pick IP65/IP66 options — these provide robust sealing and are common in tunnels, basements and parking structures. For heavy-impact zones look for IK08/IK10 rated housings. If you need vapor-tight protection (for ships, tunnels) choose a vapor-tight batten with a high-grade PC base and milky diffuser for glare control. Lumen output and light distribution (how bright and how it spreads) Decide on required lux for the space, then choose a batten with the matching lumen package. Pay attention to beam angle — a 120° beam is often ideal for even coverage in corridors and warehouses. For long runs linkable battens with consistent output reduce dark spots and make design simpler. Color temperature & color rendering (how the light looks) Pick CCTs that suit the task: 3000K for warm, human-focused spaces; 4000K as a balanced neutral; 5000K–6000K for high-visibility industrial areas. Also check CRI — a CRI above 80 is a reliable baseline for accurate color rendering in most commercial uses. Mounting & installation style (surface mount, hanging, linkable) Surface-mounted or suspended options are standard for battens — avoid recessed references. If you need long continuous lines choose linkable battens with quick wiring terminals or tool-free end caps for fast on-site wiring and reduced labor time.5. Sensors, dimming and emergency options (smart features that save money) Modern battens often have optional microwave or HF sensors (e.g., 100%–20%–OFF) and emergency backup (3+ hours at low wattage). If energy savings and safety are top of mind choose versions with motion-sensing dimming and self-test emergency function. Driver quality & flicker performance (eye comfort and longevity) A flicker-free driver improves occupant comfort and reduces complaints in offices and long-stay areas. Look for split-type power supplies or clip-fixed drivers for easy future maintenance and replacement. Warranty, certifications & lifecycle (safety and long-term value) CE, RoHS, SAA and regional approvals matter. Compare warranty terms — five-year coverage on fixtures with separate shorter battery warranties for emergency packs is common practice for industrial-grade products.

人口7000人の白川村にはコンビニが1件なのに対して人口40万人の岐阜市には200件ある。人口1万人当たりのコンビニ数はそれぞれ1.4と5である。数字を見ればコンビニ数が足りていないことは一目瞭然である。そこで、岐阜県の各市町村について人口に対するコンビニ数の比率を表示するMAPを作成する。コンビニが足りていない地域を可視化することで、コンビニオーナーの出店の動機付けになる。

我々は、按摩器や自転車などの機械製品、スマホや食洗器など家電製品を日常的に使っている。 しかし一度トラブルになった時、分厚いマニュアルを読まないといけなくなる。そういう時にアレクサなど 質問応答で答えが返ってくれると嬉しいと思ったことはないだろうか。機械がそこまで一気に賢くなるのは 難しいがそこに少しでも近づける方法を考える。マニュアルをLOD化することである。 統一された用語などにより、マニュアル作成・更新のコスト軽減が期待できる。アップルではそもそもマニュアルを作っていない。アフォーダンス理論の基に触っていくうちに使いかたが解かるように製品を開発している。しかし現状ではiTunesのように利用手順の説明が足りないケースもある。 AIでは実世界と相互作用するロボットに身体性・記号接地問題が存在するが、情報が構造化され機械可読となることで、LOD化されたマニュアルの先には質問応答システムが待っている。説明記述の整理が見込める。 統一概念が普及することでユーザーの製品理解が深まる。業界統一概念と企業独自機能・追加機能が容易に分離できる。類似製品間の比較も容易になることが見込まれる。 マニュアルLODのメリットを以下に記す。 1.複雑化・多様化する家電製品の機能説明書を継続的に改善 2.マニュアル内容をRDF化することで、情報が構造化され、説明書を表示系と内容に分離される。企業間での記述語・スタイルを統一できる道を開く。 3.マニュアル作成費用の削減、用語の統一などが期待できる。 4.RDFリポジトリに機能説明を入れることによりオープン化と継続的発展が図れる。 5.機械情報がLOD化されると機械可読となり質問応答システムなどにつなぐ道が開かれる。 6.マニュアルの自動作成などコスト削減が見込まれることでも企業からの協力が期待できる。 さしあたって現在あたってるのはスマホ操作法などを記述したマニュアルテンプレートを議論展開ツールなどで 共同構築できるWEBツールを使用することを考えている。

今夜くらいは少しだけ考えてみるシリーズの第5弾です。今回も「自分で試して考えてみる・議論する」ことができます。テーマは「就活ミスマッチの撲滅」です。学生は、個別企業へのアプローチの前に、本アプリを使って日本の産業や業界の特徴、仕事のことを定量的に把握できます。 さらに今回は「社会とのコミュニケーション機能」の追加を考えており、学生と企業の相互理解の実現を目指します。

「プロジェクトTRAIN（通勤情報を可視化することによる通勤問題解決2015）」の活動として作成したデータです。 1.データ項目 国土交通省「歩行空間データネットワークデータ整備仕様案（平成22年9月版）」の主要なデータ項目を抜粋した簡易版の「歩行空間データ」を定義しました。 －経路の種類 －供用開始時間 －供用終了時間 －供用制限曜日 －方向性 －有効幅員 －縦断勾配1(%) －縦断勾配2(フラグ) －路面状況 －段差 －最小階段段数 －最大階段段数 －手すり －屋根の有無 －蓋のない溝や水路の有無 －視覚障害者誘導用ブロック －補助施設の設置状況 －エレベーター種別 －距離 2.データ収集 2015年12月26日（土）、2016年1月5日（火）にて大井町駅にてフィールドワークを実施して、JR東日本京浜東北線改札口、東京急行電鉄（東急）大井町線改札、東京臨海高速鉄道りんかい線改札の間の、段差の有無等のバリア情報を含むバリアフリー経路案内の基盤情報となる「歩行空間データ」を作成しました。 3.作成したデータ ・GeoJSON http://ejopendataportal.maps.arcgis.com/home/item.html?id=f72aab6aa2994e749afb2e12c5898f0b ・Shapefile http://ejopendataportal.maps.arcgis.com/home/item.html?id=88834f73fcf944fa88d34bf08f2ac0ed ・CSV http://ejopendataportal.maps.arcgis.com/home/item.html?id=e222b4e6588b4f4582e138f3af5504d0